Наверное не совсем донес идею, а наоборот испугал непонятным кодом.
Он не такой уже непонятный. Чтобы понимать язык, нужно знать его слова. Джей по словам-примитивам намного богаче, чем привычные языки программирования. Например, никого не убивает в С++, операция >>, или ++, или просто скобки {}, служебное слово class и тому подобное.
Также и здесь.
Я в посте хотел объяснить именно эту логику, потому что люди думают эмоциями в таких случаях. Если вас пугает синтаксис, то это где-то аналогично, как пугаться иностранного языка и думать, что им пользуются дураки только – он же на ваш родной не похож. Это «попроще» — просто ваши ожидания от языка. Вам хочется, чтобы он сразу был понятен. Не изучая слова. Но тогда, он либо должен быть похож на естественный язык, причем желательно родной (а таких нет еще), либо не содержать слов, а позволять их побольше самому писать. В этом случае, заметьте, что вы бъете по своим воротам. Разве не надоело в каждой новой компании разбиратьяс я с новым методом DoSomethingEveryYearBefore2012? Слова понятны, но они не из языка программирования – это наносное. А наносят бог весть что. И каждый раз нет претензий к самому языку, претензии только к предыдущим именователям.
Ожидания от языка, которого вы не знаете, не всегда играют хорошую роль. Этих глаголов здесь штук 150 и за долгое время работы они становятся узнаваемыми. Правила комбинирования глаголов довольно простые. Поэтому, еще очень спорный вопрос, на каком языке код понятнее.
Далее, наиболее важный плюс джея – это работа с многомерными массивами. Т.е. представьте себе алгоритмическую сторону ваших программ. Вам часто надо создать массив. Тут делается элементарно. Хотите траспонировать? |: без проблем. Хотите развернуть список/массив. |. без проблем. Хотите уникальные элементы найти? ~. без проблем. Вот эти маленькие комбинации избавляют вас от кучи кода в других языках и вы мыслите совсем на другом уровне. Код без циклов, практически, вы только вращаете кубы, клеите их, находите пересечения, проекции – что угодно. А то, что эти операции обозначаются значками – это во-первых кода меньше, а во-вторых не особо им из нашего мира дашь подходящее название. Это векторно-массивные операции. Которыми можно легко выражать почти любой алгоритм.
Язык — прямой наследник APL, поэтому не эзотерический.
Программы читаются, но этот навык долго нарабатывается.
В данном посте читается сравнительно легко, тут в основном explicit-форма записи. Есть tacit-форма. Ее читать сложнее. Также очень зависит от кода. Если люди много скобок пишут, не могут пользоваться нормально крюками и вилками — то читается плоховато.
да, облако скорее всего сначала получится. Там будет огромная база знаний, которую пока в телефон не запихнешь, с параллельным доступом к информации с разных «телефонов», что еще полезнее, т.к. эта база будет пополняться в одном месте.
PS. «по гибкости» — я конечно подразумевал — какие структуры данных можно на С сделать. На джее попросту об этом не заморачиваются. Пусть оптимальную структуру данных подбирает интерпретатор
В J связный список не нужен. Такой список – это слишком что-то низкоуровневое. Если Вы пишете программу на относительно низкоуровневом языке, на С, то Вы создаете структуру данных из совсем слабых абстрактно примитивов. И когда Вам для некоторого алгоритма достаточно связного списка, то не нужно создавать больше функционала, на этом Вы и останавливаетесь.
J из коробки работает с массивами, причем, только с ними. Вектор – это уже и есть список. Связный список – это слишком низкоуровневые детали, говорящие об оптимальности поиска и вставок. J слишком высокоуровневый, нельзя думать о таких вещах. Создавать другие типы данных, не массивы, не имеет смысла даже потому, что все глаголы с ними работают. Глаголы являются обобщенными в плане, что можно передавать массивы с разными типы элементов, но передаваться должны массивы.
С помощью массивов из боксов (коробок, как здесь написано), можно создавать деревья. Так что можно работать с задачами, которые естественно решаются с помощью деревьев. Графы таким образом, понятно, не создадите, разве что искусственные метки придумать, потому что указателей или ссылок нет и массивы имутабельны. Но задачи с графами можно прекрасно решать матричным способом. Создаете вектор вершин и матрицу переходов.
Есть еще в J классы. Можно создать кусок кода, любой по форме, который допустим будет хранить и существительные (т.е. данные). А потом создавать экземпляры классов и каждый экземпляр будет иметь свои отдельные данные. Так что можно создать и какую-то сложную абстракцию.
J написан на С и он, конечно, не может его обогнать по гибкости и возможности оптимизаций. Он дает преимущество – рассматривание задач в другом совершенно виде, в виде матриц/массивов. Совершенно меняется взгляд на алгоритмы. Позволяет задачи решать очень кратко. При этом его быстродействие сравнимо с С.
J написан на С. Можно найти исходники. Правда их изучить не представляется возможным, потому что они на С пишут как на джее ))
Работа с памятью — сишные malloc. Выделяются массивы в куче. Единица данных — n-мерный массив. 0-мерный — скаляр, 1-мерный — вектор, 2-мерный — матрица и т.д. На счет, выделяются ли и скаляры в куче — не знаю, не интересовался.
Массив имеет всегда одинаковый тип элементов — булевский (0,1), целый, целый с любым количеством знаков, действительный с плавающей точкой, рациональный, комплексный, символьный, symbol ('sdf, 'sdfsfd — нечто похожее на символьный тип в Scheme) и боксы. Боксы — это некий аналог нетипизированных указателей. В массивах из боксов можно хранить разнотипные данные. В боксе можно хранить и другие массивы, поэтому боксами реализуются деревья, например.
Также есть специальные значения — +бесконечность, -бесконечность, неопределенность.
Надеюсь, ничего с типами не пропустил.
Надо готовить статью точно по этой теме. Всё в нем нормально. Только высокий порог вхождения. Он читаем, читаем поболее других языков. Но к этому прийти можно после нескольких лет работы на нем. Поначалу, пару месяцев, сможете только писать и только с трудом, а читать даже свой код не сможете.
На счет производительности — не правы. Он очень производителен. Даже иногда как некоторая магия воспринимается, как он умеет так относительно быстро работать, не смотря на такую высокоуровневость. Он бывает и тупит, заметно тупит, от этого никуда не деться. Тем не менее, он прекрасно работает с библиотеками, написанными на других языках, поэтому позволяет делать точечные оптимизации узких мест. Т.е. например, в нем можно вызвать функцию из библиотеки, написанной на С, и передать туда массивы, как аргументы. И сделать с ними там уже что хотите. Я работал на высоконагруженных проектах, сделанных на J. Вполне отличный язык в плане скорости создания прототипа, удовлетворительной производительности самой по себе и оптимизации проблемных участков.
Использовал его для датамайнинга. Очень хорош как язык для быстрого создания сложных алгоритмов и обработки больших массивов данных. Т.е. в финансовой сфере, для предсказаний и т.д.
Для ГУИ там тоже есть какие-то библиотеки, но убогие, правда. Ну и действительно, хотя на нем можно решать любые задачи, какие-то неалгоритмические задачи, не требующие какой-то сложной обработки данных — не будут показывать его сильные стороны. Но есть другие языки, поэтому ГУИ удобно писать на других. Да, он также мультипарадигменный. Там можно писать не только в тацитной форме (но она самая вкусная), но и императивно, с телом, ветвлениями и циклами. Также в нем есть некоторая поддержка ООП. Можно писать классы и создавать экземпляры.
Этот язык прекрасен, как вспомогательный язык в работе. Работа с ним напоминает не программирование, а вроде у вас очень мощный калькулятор. Вы быстро можете проверить любую идею, что-то даже распарсить или сгенерировать код для другого языка. Когда на нем пишете, то ощущение, что вы быстро что-то сооружаете одноразовое. Он не заставляет думать и продумывать архитектуру, не заставляет думать, что вы что-то делаете на века. Это в общем — достоинство. У вас меньше страха перед ошибкой именно потому, что всё получается быстро. Такой себе очень сильный математический калькулятор.
Минусы скорее только такие: высокая сложность, не надейтесь научиться ему быстро. Я изучил его за месяц (прочитал книгу и запомнил все глаголы, примеры и т.д.). Еще с месяц писал первое задание, которое придумал. Это всё по вечерам. Но привыкал с год, более менее читать. И дальше тоже развивался. И думаю, еще не достиг идеала понимания этого языка. Хотя со временем он становится понятнее и понятнее.
Эта сложность языка является и причиной другого минуса — мало кадров. Т.е. выбирая его под проект, вы рискуете не найти людей.
Понятно. Спорить в общем-то нечего, у нас разные мировоззрения.
Я не утверждаю, если что, что работа должна быть ненавистной и надо ее выполнять с настроением мытья посуды. Просто думаю, что должен приносить удовлетворение процесс, а не результат. Мотивировать себя на результат — это на слишком короткие дистанции. Никто так не становится чемпионом в спорте. Никто не станет хорошим программистом, желая всего лишь взять эту высоту. Только привычка работать и только работа, долгосрочная к этому приводит. А выбрать себе деятельность, которая еще и приносит удовольствие как процесс (в моем случае программирование) — это вообще удача.
Это то же самое, только в профиль. Т.е. «стать известным» в какой-то сфере. Когда всё, что надо, есть, еще бы славы )))
По моему, это не коррелирует даже с желанием знать побольше, делать работу качественнее, интересом и любовью к программированию. По крайней мере, я не встречал много людей, которые искренне желают быть известными. Но если хотят, то пусть добиваются. Тем не менее, я не вижу причин на собеседованиях ставить это во главу угла.
Получать от работы удовольствие, конечно, важно. Но, ИМХО, эмоции — лишнее.
Хотя бы потому, что если Вы сделаете
комплексную программу проектов общим объемом 6000 чел.*мес. Для меня это вызов.
, после этого за подобную задачу не будет интересно браться. А как быть опытному программисту, когда он уже поучаствовал в нескольких десятках проектов, многие сделал сам, и они охватывают уже все интересные для него сферы? Бросать работу и идти в космонавты ))
Озвучить можно мягко, конечно. Честным быть хорошо.
Но это так же и очевидно. Если человек на собеседовании начнет прямо говорить, что меняет работу ради +ХХХ денег, то как-то не сумел выглядеть немеркантильным, жаждущим знаний, с четкой жизненной позицией и т.д. (прямо по статье). А если еще добавит, что мудаки на прошлой работе достали )))) Тогда Вы его точно не возьмете.
Но ведь человек в первую очередь решает свои личные проблемы. Не надо врать, что он за идею работает.
Конечно, когда опыт большой, когда уже нет особой разницы — везде платят хорошо, то иногда могут найти какой-то интересный плюс в какой-то другой компании. Вроде командировок в Лондон или просто компания более известная. Но опять же, по этим причинам с текущей работы не уходят. Уходят только тогда, когда вынуждают более веские причины.
за всех и сразу отвечу: практически всегда уходят по одной из двух причин или двум сразу — первое, хотят больше зп, второе — напряженные отношения в коллективе (часто с начальством). Ни первое ни второе на собеседованиях никто в своем уме озвучивать не будет.
По-моему, плохой вариант собеседования. Хотя верно, вы же ищете похожих по менталитету, вы и барин.
«Нет «горения» — минус» и «Зрелость личности» — несовместимые вещи. Студентам огня в глазах хоть отбавляй.
Когда компания на собеседованиях давит на то, что им нужны амбициозные люди, с огнем в глазах, у меня сразу же появляется перевод: компания ищет раба за небольшие деньги. На чем еще можно играть, урезая бюджет? На мифических нематериальных бонусах, вроде получения бесценного опыта в интереснейшем проекте лучшей в мире компании.
Зрелость личности — это умение работать без особых мотивационных заморочек. Стрелянный волк, т.е. опытный программист видел разные проекты, все время работает. Работа — это просто рутина и те, кто умеют делать рутину — настоящие профессионалы. Достигают результатов в чем либо только те, кто работает над чем-то каждый день, переводит занятие в привычку. Огни в глазах перегорают за месяц.
Когда слышу слово «воля», «успех» и тому подобное, возникают те же стойкие ассоциации, что либо хотят нанять студента, либо просто общаюсь с человеком с другой по сравнению с моей планетой. Воля нужна для того, чтобы что-то преодолевать. Что-то преодолевать нужно, если есть внутренние барьеры. Внутренние барьеры к работе возникают, только если человек не самоорганизован. Несамоорганизованность появляется от безделья.
Успех — это вообще жесткий мем. Современная промывка мозгов. Как-то без конца слышал про успех, успешность, успешных людей. Ни разу не говорилось, что это успешный хирург (не по баблу, а по знаниям), или успешный физик (10 лет изучал физику и обрел знания). Нет, сейчас успех — это самостоятельное слово. Как бы настолько нагло промывают мозги, мол «вы же сами понимаете, что значит успех».
Прошу прощения за косноязычность. Конечно, я не подразумевал, что ради единственного Last() надо кругом всё превращать в массивы. Ответ немного выше.
Но снова об оптимизации. Зло это. Вообще, думать об оптимизации. Я со всем согласен и с Вами и с постом, не нравится только ракурс — рассматривание проблемы с т.з. того, как это плохо — многократные итерации. И Ваша т.з. — как это плохо — складирование строк в памяти. Как вроде ничего больше в программировании интересного и нет )
Но вообще, действительно, надо выбирать компромисс. Last() — не является родной операцией для IEnumerable(), но при этом, бессмысленно для одного Last() делать какое-то копирование в массив. Там, внутри Last тоже делается свое либо приведение либо какие-то оптимизации, чтобы находить последний элемент без приведения.
Добавить своих расширяющих методов можно. Часто передаются IEnumerable<> кругом. Но при этом, если программисты пользуются в своим коде List<>. Чтобы не идти на компромиссы, выбирая, что же надо передавать кругом — связный список (IEnumerable<>) или список с индексным доступом(IList<>), а ToList() делает копию, что бывает накладно, то можно добавить такой метод:
IReadOnlyList<> ToReadOnlyListByRefOrCopy(...)
А там проверять, если это список, то приводить просто по ссылке и возвращать враппер, если нет — враппер над копией.
Таким образом получите некий компромисс между производительностью и выразительностью кода. Как только нужен индексный доступ — вызвали этот метод.
Типами можно хорошо описывать намерения. Не всегда всё гладко получается и с типизацией проблемы, но имхо, лучше уже так, чем просто беспорядочно IEnumerable<> использовать.
У IEnumerable просто даже нет последнего элемента по смыслу. Это просто множество без заданного порядка. Нет гарантии, что два перебора дадут тот же самый порядок и что один и тот же элемент будет в конце.
Сложная тема. Последняя строка как по мне — недостаточно. Поиск последней строки — это тоже индексный поиск. Также Count() — неродная операция.
У интерфейсов есть назначение. IEnumerable нужен только для перебора, возможно бесконечных множеств. Если программист объявляет такой тип, он это и декларирует — ему надо перебрать, ему не важен порядок элементов (индексы) и т.д.
ElementA(), Last(), Count() — это всё экстеншин методы, они не входят в IEnumerable. По моему, типами, программист также говорит о том, что он собирается делать. Это улучшает читаемость.
Если бы C# был таким чистым функциональным языком с немутабельными типами — то особых проблем бы не было с вызовом этих методов и с итерациями. Можно бы было один список, как в Lisp использовать для всего. C# не может гарантировать в общем случае, что в множестве не изменяются элементы от вызова к вызову, поэтому не может использовать ленивые оптимизации.
А поэтому, лучше использовать правильные типы.
Если нужен индексный доступ, то по смыслу самому List (в смысле вектор для плюсовиков) подходит явно. Конечно, на любых переборах, не зависимо от структуры данных программист может найти по индексу элемент. И не должен задумываться, что там за структура.
Но и интерфейсы тоже не говорят, что за структуры на самом деле используются. Поэтому тут дело не в оптимизации. Если программист в методе решил использовать индексный доступ, то он декларирует это типом переменной.
Повсеместное использование в сигнатурах методов IEnumerable нарушает принципы программирования по контракту и ведет к ошибкам.
Неожиданный вывод. IEnumerable только говорит о том, что программист собрался перебрать элементы, не более. И очень часто именно это и надо, чаще, чем остальные случаи.
var lines = File.ReadLines("data.txt");
string lastLine = lines.ElementAt(lines.Count());
Говорит только о том, что здесь явно не IEnumerable нужен. ElementAt — это просто не родная операция для него. Если решили использовать Count() или ElementAt() — то скорее контракт нарушен, когда заводили переменную/параметр типа IEnumerable
Он не такой уже непонятный. Чтобы понимать язык, нужно знать его слова. Джей по словам-примитивам намного богаче, чем привычные языки программирования. Например, никого не убивает в С++, операция >>, или ++, или просто скобки {}, служебное слово class и тому подобное.
Также и здесь.
Я в посте хотел объяснить именно эту логику, потому что люди думают эмоциями в таких случаях. Если вас пугает синтаксис, то это где-то аналогично, как пугаться иностранного языка и думать, что им пользуются дураки только – он же на ваш родной не похож. Это «попроще» — просто ваши ожидания от языка. Вам хочется, чтобы он сразу был понятен. Не изучая слова. Но тогда, он либо должен быть похож на естественный язык, причем желательно родной (а таких нет еще), либо не содержать слов, а позволять их побольше самому писать. В этом случае, заметьте, что вы бъете по своим воротам. Разве не надоело в каждой новой компании разбиратьяс я с новым методом DoSomethingEveryYearBefore2012? Слова понятны, но они не из языка программирования – это наносное. А наносят бог весть что. И каждый раз нет претензий к самому языку, претензии только к предыдущим именователям.
Ожидания от языка, которого вы не знаете, не всегда играют хорошую роль. Этих глаголов здесь штук 150 и за долгое время работы они становятся узнаваемыми. Правила комбинирования глаголов довольно простые. Поэтому, еще очень спорный вопрос, на каком языке код понятнее.
Далее, наиболее важный плюс джея – это работа с многомерными массивами. Т.е. представьте себе алгоритмическую сторону ваших программ. Вам часто надо создать массив. Тут делается элементарно. Хотите траспонировать? |: без проблем. Хотите развернуть список/массив. |. без проблем. Хотите уникальные элементы найти? ~. без проблем. Вот эти маленькие комбинации избавляют вас от кучи кода в других языках и вы мыслите совсем на другом уровне. Код без циклов, практически, вы только вращаете кубы, клеите их, находите пересечения, проекции – что угодно. А то, что эти операции обозначаются значками – это во-первых кода меньше, а во-вторых не особо им из нашего мира дашь подходящее название. Это векторно-массивные операции. Которыми можно легко выражать почти любой алгоритм.
Программы читаются, но этот навык долго нарабатывается.
В данном посте читается сравнительно легко, тут в основном explicit-форма записи. Есть tacit-форма. Ее читать сложнее. Также очень зависит от кода. Если люди много скобок пишут, не могут пользоваться нормально крюками и вилками — то читается плоховато.
J из коробки работает с массивами, причем, только с ними. Вектор – это уже и есть список. Связный список – это слишком низкоуровневые детали, говорящие об оптимальности поиска и вставок. J слишком высокоуровневый, нельзя думать о таких вещах. Создавать другие типы данных, не массивы, не имеет смысла даже потому, что все глаголы с ними работают. Глаголы являются обобщенными в плане, что можно передавать массивы с разными типы элементов, но передаваться должны массивы.
С помощью массивов из боксов (коробок, как здесь написано), можно создавать деревья. Так что можно работать с задачами, которые естественно решаются с помощью деревьев. Графы таким образом, понятно, не создадите, разве что искусственные метки придумать, потому что указателей или ссылок нет и массивы имутабельны. Но задачи с графами можно прекрасно решать матричным способом. Создаете вектор вершин и матрицу переходов.
Есть еще в J классы. Можно создать кусок кода, любой по форме, который допустим будет хранить и существительные (т.е. данные). А потом создавать экземпляры классов и каждый экземпляр будет иметь свои отдельные данные. Так что можно создать и какую-то сложную абстракцию.
J написан на С и он, конечно, не может его обогнать по гибкости и возможности оптимизаций. Он дает преимущество – рассматривание задач в другом совершенно виде, в виде матриц/массивов. Совершенно меняется взгляд на алгоритмы. Позволяет задачи решать очень кратко. При этом его быстродействие сравнимо с С.
Работа с памятью — сишные malloc. Выделяются массивы в куче. Единица данных — n-мерный массив. 0-мерный — скаляр, 1-мерный — вектор, 2-мерный — матрица и т.д. На счет, выделяются ли и скаляры в куче — не знаю, не интересовался.
Массив имеет всегда одинаковый тип элементов — булевский (0,1), целый, целый с любым количеством знаков, действительный с плавающей точкой, рациональный, комплексный, символьный, symbol ('sdf, 'sdfsfd — нечто похожее на символьный тип в Scheme) и боксы. Боксы — это некий аналог нетипизированных указателей. В массивах из боксов можно хранить разнотипные данные. В боксе можно хранить и другие массивы, поэтому боксами реализуются деревья, например.
Также есть специальные значения — +бесконечность, -бесконечность, неопределенность.
Надеюсь, ничего с типами не пропустил.
На счет производительности — не правы. Он очень производителен. Даже иногда как некоторая магия воспринимается, как он умеет так относительно быстро работать, не смотря на такую высокоуровневость. Он бывает и тупит, заметно тупит, от этого никуда не деться. Тем не менее, он прекрасно работает с библиотеками, написанными на других языках, поэтому позволяет делать точечные оптимизации узких мест. Т.е. например, в нем можно вызвать функцию из библиотеки, написанной на С, и передать туда массивы, как аргументы. И сделать с ними там уже что хотите. Я работал на высоконагруженных проектах, сделанных на J. Вполне отличный язык в плане скорости создания прототипа, удовлетворительной производительности самой по себе и оптимизации проблемных участков.
Использовал его для датамайнинга. Очень хорош как язык для быстрого создания сложных алгоритмов и обработки больших массивов данных. Т.е. в финансовой сфере, для предсказаний и т.д.
Для ГУИ там тоже есть какие-то библиотеки, но убогие, правда. Ну и действительно, хотя на нем можно решать любые задачи, какие-то неалгоритмические задачи, не требующие какой-то сложной обработки данных — не будут показывать его сильные стороны. Но есть другие языки, поэтому ГУИ удобно писать на других. Да, он также мультипарадигменный. Там можно писать не только в тацитной форме (но она самая вкусная), но и императивно, с телом, ветвлениями и циклами. Также в нем есть некоторая поддержка ООП. Можно писать классы и создавать экземпляры.
Этот язык прекрасен, как вспомогательный язык в работе. Работа с ним напоминает не программирование, а вроде у вас очень мощный калькулятор. Вы быстро можете проверить любую идею, что-то даже распарсить или сгенерировать код для другого языка. Когда на нем пишете, то ощущение, что вы быстро что-то сооружаете одноразовое. Он не заставляет думать и продумывать архитектуру, не заставляет думать, что вы что-то делаете на века. Это в общем — достоинство. У вас меньше страха перед ошибкой именно потому, что всё получается быстро. Такой себе очень сильный математический калькулятор.
Минусы скорее только такие: высокая сложность, не надейтесь научиться ему быстро. Я изучил его за месяц (прочитал книгу и запомнил все глаголы, примеры и т.д.). Еще с месяц писал первое задание, которое придумал. Это всё по вечерам. Но привыкал с год, более менее читать. И дальше тоже развивался. И думаю, еще не достиг идеала понимания этого языка. Хотя со временем он становится понятнее и понятнее.
Эта сложность языка является и причиной другого минуса — мало кадров. Т.е. выбирая его под проект, вы рискуете не найти людей.
Я не утверждаю, если что, что работа должна быть ненавистной и надо ее выполнять с настроением мытья посуды. Просто думаю, что должен приносить удовлетворение процесс, а не результат. Мотивировать себя на результат — это на слишком короткие дистанции. Никто так не становится чемпионом в спорте. Никто не станет хорошим программистом, желая всего лишь взять эту высоту. Только привычка работать и только работа, долгосрочная к этому приводит. А выбрать себе деятельность, которая еще и приносит удовольствие как процесс (в моем случае программирование) — это вообще удача.
Это то же самое, только в профиль. Т.е. «стать известным» в какой-то сфере. Когда всё, что надо, есть, еще бы славы )))
По моему, это не коррелирует даже с желанием знать побольше, делать работу качественнее, интересом и любовью к программированию. По крайней мере, я не встречал много людей, которые искренне желают быть известными. Но если хотят, то пусть добиваются. Тем не менее, я не вижу причин на собеседованиях ставить это во главу угла.
Получать от работы удовольствие, конечно, важно. Но, ИМХО, эмоции — лишнее.
Хотя бы потому, что если Вы сделаете, после этого за подобную задачу не будет интересно браться. А как быть опытному программисту, когда он уже поучаствовал в нескольких десятках проектов, многие сделал сам, и они охватывают уже все интересные для него сферы? Бросать работу и идти в космонавты ))
Но это так же и очевидно. Если человек на собеседовании начнет прямо говорить, что меняет работу ради +ХХХ денег, то как-то не сумел выглядеть немеркантильным, жаждущим знаний, с четкой жизненной позицией и т.д. (прямо по статье). А если еще добавит, что мудаки на прошлой работе достали )))) Тогда Вы его точно не возьмете.
Но ведь человек в первую очередь решает свои личные проблемы. Не надо врать, что он за идею работает.
Конечно, когда опыт большой, когда уже нет особой разницы — везде платят хорошо, то иногда могут найти какой-то интересный плюс в какой-то другой компании. Вроде командировок в Лондон или просто компания более известная. Но опять же, по этим причинам с текущей работы не уходят. Уходят только тогда, когда вынуждают более веские причины.
«Нет «горения» — минус» и «Зрелость личности» — несовместимые вещи. Студентам огня в глазах хоть отбавляй.
Когда компания на собеседованиях давит на то, что им нужны амбициозные люди, с огнем в глазах, у меня сразу же появляется перевод: компания ищет раба за небольшие деньги. На чем еще можно играть, урезая бюджет? На мифических нематериальных бонусах, вроде получения бесценного опыта в интереснейшем проекте лучшей в мире компании.
Зрелость личности — это умение работать без особых мотивационных заморочек. Стрелянный волк, т.е. опытный программист видел разные проекты, все время работает. Работа — это просто рутина и те, кто умеют делать рутину — настоящие профессионалы. Достигают результатов в чем либо только те, кто работает над чем-то каждый день, переводит занятие в привычку. Огни в глазах перегорают за месяц.
Когда слышу слово «воля», «успех» и тому подобное, возникают те же стойкие ассоциации, что либо хотят нанять студента, либо просто общаюсь с человеком с другой по сравнению с моей планетой. Воля нужна для того, чтобы что-то преодолевать. Что-то преодолевать нужно, если есть внутренние барьеры. Внутренние барьеры к работе возникают, только если человек не самоорганизован. Несамоорганизованность появляется от безделья.
Успех — это вообще жесткий мем. Современная промывка мозгов. Как-то без конца слышал про успех, успешность, успешных людей. Ни разу не говорилось, что это успешный хирург (не по баблу, а по знаниям), или успешный физик (10 лет изучал физику и обрел знания). Нет, сейчас успех — это самостоятельное слово. Как бы настолько нагло промывают мозги, мол «вы же сами понимаете, что значит успех».
Но снова об оптимизации. Зло это. Вообще, думать об оптимизации. Я со всем согласен и с Вами и с постом, не нравится только ракурс — рассматривание проблемы с т.з. того, как это плохо — многократные итерации. И Ваша т.з. — как это плохо — складирование строк в памяти. Как вроде ничего больше в программировании интересного и нет )
msdn.microsoft.com/en-gb/library/hh881542.aspx
Но вообще, действительно, надо выбирать компромисс. Last() — не является родной операцией для IEnumerable(), но при этом, бессмысленно для одного Last() делать какое-то копирование в массив. Там, внутри Last тоже делается свое либо приведение либо какие-то оптимизации, чтобы находить последний элемент без приведения.
Добавить своих расширяющих методов можно. Часто передаются IEnumerable<> кругом. Но при этом, если программисты пользуются в своим коде List<>. Чтобы не идти на компромиссы, выбирая, что же надо передавать кругом — связный список (IEnumerable<>) или список с индексным доступом(IList<>), а ToList() делает копию, что бывает накладно, то можно добавить такой метод:
IReadOnlyList<> ToReadOnlyListByRefOrCopy(...)
А там проверять, если это список, то приводить просто по ссылке и возвращать враппер, если нет — враппер над копией.
Таким образом получите некий компромисс между производительностью и выразительностью кода. Как только нужен индексный доступ — вызвали этот метод.
Типами можно хорошо описывать намерения. Не всегда всё гладко получается и с типизацией проблемы, но имхо, лучше уже так, чем просто беспорядочно IEnumerable<> использовать.
У интерфейсов есть назначение. IEnumerable нужен только для перебора, возможно бесконечных множеств. Если программист объявляет такой тип, он это и декларирует — ему надо перебрать, ему не важен порядок элементов (индексы) и т.д.
ElementA(), Last(), Count() — это всё экстеншин методы, они не входят в IEnumerable. По моему, типами, программист также говорит о том, что он собирается делать. Это улучшает читаемость.
Если бы C# был таким чистым функциональным языком с немутабельными типами — то особых проблем бы не было с вызовом этих методов и с итерациями. Можно бы было один список, как в Lisp использовать для всего. C# не может гарантировать в общем случае, что в множестве не изменяются элементы от вызова к вызову, поэтому не может использовать ленивые оптимизации.
А поэтому, лучше использовать правильные типы.
Но и интерфейсы тоже не говорят, что за структуры на самом деле используются. Поэтому тут дело не в оптимизации. Если программист в методе решил использовать индексный доступ, то он декларирует это типом переменной.
Неожиданный вывод. IEnumerable только говорит о том, что программист собрался перебрать элементы, не более. И очень часто именно это и надо, чаще, чем остальные случаи.
Говорит только о том, что здесь явно не IEnumerable нужен. ElementAt — это просто не родная операция для него. Если решили использовать Count() или ElementAt() — то скорее контракт нарушен, когда заводили переменную/параметр типа IEnumerable