Компания HackerRank (https://en.wikipedia.org/wiki/HackerRank), специализирующаяся на проведении конкурсов среди разработчиков и найме программистов, опубликовала (https://research.hackerrank.com/developer-skills/2019) результаты (PDF (http://info.hackerrank.com/rs/487-WAY-049/images/HackerRank_... online-опроса более 71 тыс. разработчиков ПО, проживающих в более чем 100 странах. Аналогичный опрос проводился год назад. Некоторые интересные тенденции:
- JavaScript обогнал Java в рейтинге наиболее известных языков: 73% разработчиков заявили, что знают JavaScript, при этом о знании Java сообщили 71% опрошенных. Год назад JavaScript набрал 68%, а Java - 71%.
Язык Си набрал 67%, Python - 57%, C++ - 55%, PHP - 38%.
- Среди языков, которые разработчики хотели бы изучить, лидируют Go, Kotlin и Python. По сравнению с прошлым годом, заметно уменьшился интерес к изучению Scala и возрос интерес к TypeScript;- Наиболее популярным Web-фреймворком остаётся AngularJS (как по знанию разработчиками, так и по запросам работодателей), но по сравнению с прошлым годом отмечается заметный рост интереса к изучению React - число разработчиков знающих React увеличилось с 20% до 26%.
Выросло также число предложений работодателей, которым необходимы специалисты со знанием React;
- Наиболее перспективными направлениями развития называются IoT-устройтва (53%), системы машинного обучения (51%), облачные сервисы на базе машинного обучения (41%) и разработки в области компьютерного зрения (38%). В качестве наиболее переоценённой технологии называются решения на базе блокчейна;
- Из проблем, мешающих работе лидирует некачественная документация, рутина, некорректная расстановка приоритетов, рассмотрение прогнозов как жёстких планов и отладка трудновоспроизводимых ошибок;
- На вопрос о наиболее крупном провале 62% опрошенных отметили поставку непротестированного или явно проблемного кода в конечном продукте, а 10% указали на случаи удаления по ошибке всего содержимого БД.
URL: https://venturebeat.com/2019/01/29/hackerrank-developer-skil.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=50077
> HR-контора
> разработчики заявили, что знаютОй, да люди чего только в резюме не пишут.
Я знаю самбо, дзюдо, карате и еще много других страшных слов.
а я не только знаю, но даже видел и что самое СТРАШНОЕ изучал ..... кое что... ахахах))) но ява скрипт? действительно более пугающий))
> Я знаю самбо, дзюдо, карате и еще много других страшных слов.дзюдо и дзюпосле
Пластиковый мир победил, JS оказался сильней...
Это ничего не значит. Ты можешь писать на чём хочешь. Инфа 146%.
ты врёшь, 146% не бывает
если референдум проводить
Вообще-то если быть видеоинженером, случайно пристроенным потом в штатах.Понимаю, что тема про разработку, а не администрирование, но элементарные навыки инфобезопасности и разработчику вообще-то важны, чтоб мир не становился пластиковым ещё быстрей.
> если быть видеоинженером, случайно пристроенным потом в штатах.Чурова в штатах разве что в качестве лабораторного животного возмут.
>Инфа 146%.Куда делись ещё 452%, ирод? http://www.rg-rb.de/index.php?option=com_rg&task=item&id=184...
Бредовый рейтинг бекенд и фронтенд фреймворков в 1 списке.
> Бредовый рейтинг бекенд и фронтенд фреймворков в 1 списке.Это был камень в огород НОДЫ ?
И кстати ЖАВУ знать можно ЖС вряд ли, есть мнение что дажы разрабы до сих пор ЕСМА не знают достаточно хорошо ;)
Нет это камень в сторону того что там у них ануляр, вью, реакт и спринг, джанго, экспресс в одном списке, хотя это фундаментально разные вещи.
вот
,
Ага, и Angular 2+ считают вместе с AngularJS, общего между которыми нет ничего, кроме названия.
Рейтинг ни о чем. Ну слышали разработчики о JS чаще, чем о Java. И что? А когда будет статистика о цветовых предпочтениях разработчиков? Какие цвета им больше всего нравятся.
в этом рейтинге js, java, go и kotlin, поэтому голубой. опрос тут не нужен, всё очевидно
очередной гендерный шовинист, посмотрите-ка!
(разумеется, women can't code, но "предпочтения" вполне иметь могут, и называться "разработчиками" запросто - так что там все цвета радуги. Гм. Даже и не знаю, кто тут победит.)
Какой-то странный рейтинг. Уже давно ведущим фрамеворком/библиотекой обосновался React, а тут выставлен внезапно Angular и типо React догоняет :) По многим другим опросам, люди хотят освоить Rust, а тут откуда-то вылезает Go. А Vue, вообще болтается где-то в середине.
очевидно, говорите ерунду. на самом деле самый распространённый набор библиотек - qt. по поводу ангуляров: это не библиотеки. библиотеки это всегда бинарные файлы, ваши наборы скриптов называйте как хотите иначе. язык, который все хотят изучить, это, неоспоримый факт, - nim. языки, агрессивно рекламируемые ТНК (Котлин, ГОУ и прочие расты) никому не интересны. это я про нормальных людей, которые в подобного рода опросах не могут участвовать физически, т.к. никогда на них не наткнутся. именно поэтому рейтинг странный, а не по вашим юношеским веб-догадкам. как вообще можно js называть языком программирования?
> библиотеки это всегда бинарные файлы, ваши наборы скриптов называйте как хотите иначе.Т.е. у питона стандартной библиотеки нет, из сишной -- нужно срочно удалить все макросы, константы, типы и прочее?
макросы - зло!
Не сметь трогать святое!Макросы были, есть и еще вас всех переживут.
Языки активно продвигаемые ТНК позволяют активно и много зарабатывать разрабам. А экзотика чаще всего ценится лишь в зоопарке. И кто здесь страдает юношество ещё большой вопрос. В жизни это выглядело бы так, что какой нибудь слесарь пытался доказать всем что с помощью молотка он не только гвозди может забивать, но и гнуть рельсы и распускать бревна на доски. На заре java фанаты с++ прочили ей скорый провал и забвение. Чем показали лишь собственную некомпетентность в цифровом бизнесе. Тот случай, когда кодер дальше своего носа ничего не видит.
Как писал вчерась, мне очень сильно кажется, что жабу делали даже не столько с целью побольше впаривать санок (и поменьше страдать от того, что разработчики побежали на винтел) -- а для того, чтоб манагеры всё-таки смогли в _предсказуемые_ -- не путать с оптимальными -- сроки выбить из толпы индусских кодеров "продухт".
Ну так это, вроде, никогда секоетрм и не было - индустрия не может держаться на "гениях", нужен массовый более-менее предсказуемый выход продукции.Желательно подешевле, конечно, но тут как пойдёт. И чем больше масштаб - тем предсказуемость важнее, так как любые потрясения дороже обходятся, а привходящих обстоятельств - больше.
Рискуя вызвать потоки помоев в свой адрес от адептов "истинных ЯП всех времен и народов", напомню что успех современных мобильных платформ связан как раз с тем, что чувачки из Sun своевременно запарились вопросом создания ЯП для этих платформ. Если бы разработка велась на сях и плюсах, то сотовой связь была бы тем еще геммороем для пользователей, линуксоиды, подите же сюда, и расскажите ламерам как семь пядей во лбу необходимы чтобы грамотно настроить и юзать софт под лучшую в мире платформу. Все остальным - RTFM и плакать. Неосиляторам не нашлось бы места в чудном новом мире мобильной связи.
Успех нынешних мобильных платформ связан с появлением iPhone, где native-only приложения. Google сейчас страдает именно от того, что решили быть "как все" и тем самым переманить разработчиков кнопочных мобил. И даже вкостылили JIT-кеш. Успех Java обусловлен в основном тем, что их маркетологи убеждали, что никакие альтернативы не нужны. И разработчики сталкивались с выбором: учи Java или забей на мобилки.
>Как писал вчерась, мне очень сильно кажется, что жабу делали
>сроки выбить из толпы индусских кодеров "продухт"Когда создавали JavaVM, в Индиии считали максимум на калькуляторах.
мой приятель преподавал понаехавшим копченым кумарам и китайцам разный всякий матан еще в 1986м.про индусский код было нихрена не выдумкой - уже тогда.
не на том сосредоточились батенька. для чего нужны библиотеки? обычно в них выносятся функции и прочие конестанты , которые потребуются для вызова. или прописывайте батенька каждый раз одну и туже функцию в коде. тогда правда вам либы вообще нафиг не сдались. но полагаю программа которая обычно состоит из 1000 строк будет 10000 строк, если не больше. таким образом библиотеки в питоне все таки есть, хоть и "бинарные" как вы выразились. не путайте теплое с мягким. библиотеки создаются не для бинарности.))
там "не бинарные"))
>языков, которые разработчики хотели бы изучитьЯ на С++ пишу около 10 лет. И до сих пор хочу его изучить, но всё как-то не получается...
Я больше поржал, когда увидел количество знающих C...
скоро меньше станет. из универов потихоньку выпиливают единственный семестр изучения си, поэтому школьники даже знать не будут, что есть такой язык
И это правильно. Нечего небезопасным языкам делать в современном мире - для системщины есть Rust, для аппликух Java/C#/Swift, для скриптоты и ML - питон, для веба - JS.Остальное может заворачиваться в простыню и ползти в сторону кладбища, давно пора.
> для скриптоты и ML - питон,для "скриптоты" есть Go и Ruby.
для ML есть Julia и RСлова "питон" в лексиконе современного разработчика быть не должно.
Кхм, таких наивных верующих во все времена хватало. Примерно с таким же апломбом чуть раньше пропихивали функциональщину, например. А по факту - количество реально используемых языков только увеличивается, потому как сфера применения всё шире. И конца этому не видать.Ну и факт остаётся фактом - кто, как минимум, начинает с "небезопасных" сей или ассемблера - тот может перебраться при необходимости на что угодно, есть и понимание, как оно работает. Кто начинает с языков, примерно полностью состоящих из магии компилятора/рантайма - испытывает проблемы при переходе куда-то, где магия другая, а в своей области не имеет вменяемой ментальной модели на тему что возможно, что нет и какова внутренняя логика системы. Что, понятно, не критично при избыточных ресурсах... а потом прилетает обломинго.
с коих пор асм не безопасный?
Память, строки?
чаво? пять и строки? ))))) строки появились в Си, в асм их нет, там последовательность байт.
Что, правда в асме нет строк? Чувак, тебя твой школьный учитель информатики жестоко обманул.
Если мне не изменяет память, то в TASM-e это выглядело как-то так:
str db 'Hello World!'
ну или
str db 'Hello World!',0К тому же странно было бы, если в языке есть команды работы со строками, а строк нет.
)))) мда уж, а давайте по порядку
str db 'Hello World!'что такое str, что такое db, и что такое 'Hello World!'?
ну собственно ,0 что за магический символ )))
>если в языке есть команды работы со строками, а строк нет.
))))) давайте вспомним что такое строки, в первую очередь, это алфавит, во-вторую, алфавит это буквы, из букв состоят слова, из слов - предложения. "Строка" в асм - набор символов, символы представляются набором байт, в зависимости от размера - образуется "машинные слова", да и асм не работает со строками, а с машинными словами. И никаких строк. Строки только в представлении.
db - define byte
пс: в том же NASM - DB, DW, DD, DQ, DT, DDQ, DO - являются псевдо инструкциями.
> db - define byteТак то можно сказать, что и в Си строк нет; char это самое маленькое число какое только система в состоянии адресовать, то есть синоним слова байт. Вот если бы в ассемблере можно было вводить строки только так: str db 48h, 65h, 6Ch, 6Ch, 6Fh, 20h, 57h, 6Fh, 72h, 6Ch, 64h, 21h, 0h. То можно было бы сказать, что в ассемблере нет строк, а так только HEX-коды могут похвастаться тем, что в них нет строк.
>Так то можно сказать, что и в Си строк нет;Как такого типа как "строка" - нет, есть понятие последовательности символов, байт, битов и т. д. Приведу пример, дом состоит из блоков кирпичей, кирпич есть базовый строительный элемент, а вот дом разве можно назвать строительным элементом?
Отдельного явно выделенного типа данных в асме нет, но строки есть. Смирись с этим, это факт. И в следующий раз более аккуратно делай подобные анонсы.
Это ты прикалываешься, или как?
кхммм - на полном серьезе
по запросу в гуглях "assembler secure coding" увы ничего нет. как это объяснить?
Это потому что белки-истерички от "безопасности" ассемблеров-то и не знают.
1) я бы искал assembly, а не assembler - но это так, между прочим
2) ничего нет, потому что запрос безумен - ассемблер тем и интересен (там, где он интересен), что не налагает дополнительных ограничений на разработчика - в том числе мерами, направленными на обеспечение безопасности. Всё, что дали процессор с ОС (если она есть) - всё твоё, семантика не энфорсится никак.
1) Походу гуглу без разницы, внимание привлекла только данная ссылка из выдачиhttps://courses.cs.washington.edu/courses/cse484/14au/readin...
))) ага там нет и близко про асм
2) безумен?, убили))))))
>в том числе мерами, направленными на обеспечение безопасности
Повторю Шнайера "Security is a process, not a product".
> кхммм - на полном серьезеНе верится что-то. Больше позоже на троллинг, и не очень тонкий.
> по запросу в гуглях "assembler secure coding" увы ничего нет. как это объяснить?
Как можно объяснить вранье? У меня гугл более 6 миллионов страниц по этому запросу нашел.
"Луна сделана из сыра, как это объяснить?" - и, ага, трудись-объясняй
>У меня гугл более 6 миллионов страницТок не вижу ни одной у вас в коменте, в студию плиз.
пс: Толсто про 6 миллионов, слив засчитан
> гугл не вижуhttp://lmgtfy.com/?q=assembler+secure+coding
> Толсто
Хотел написать "не толще, чем у тебя", но так уж и быть, пусть будет толще :)
> слив засчитан
Ага, как аргументы кончились, так сразу толсто и слив засчитан :)
> http://lmgtfy.com/?q=assembler+secure+codingэто ссылка на статью о безопасном кодинге асм или на результаты поисковика?
Особенно ся близки к тому, "как оно работает"...
Функциональщина, которую якобы "пропихивали", родилась тогда, когда подавляющее большинство анонимов с опеннета еще в проекте даже не было. С тех пор она один раз была задвинута подальше, так как программировать стало проще и навалилась куча "модномолодежных" программистов, верующих в святой императив и ООП.Но, как оказалось, во очень многих задачах функциональный подход существенно более оптимален. Поэтому и стали переоткрываться функциональные подходы. Например, тот же linq в шарпе, руби вон всякие )
> Ну и факт остаётся фактом - кто, как минимум, начинает с "небезопасных" сей или ассемблера - тот может перебраться при необходимости на что угодно, есть и понимание, как оно работает. Кто начинает с языков, примерно полностью состоящих из магии компилятора/рантайма - испытывает проблемы при переходе куда-то...
А-ХА-ХА-ХА-ХА! Проблем с программированием не испытывает тот, кто начинает с алгоритмизации; и ему уже совершенно фиолетово на каком языке потом описать свой алгоритм.
Видел я этих мамкиных ассемблерщиков, которые пытаются простые задачи разложить на кубики "а для конкатенации строк нам нужен эффективный алгоритм" и не могущие реализовать элементарное вейвлет преобразование.А алгоритмизацию, дорогие, надо учить на языках, на которых не надо два месяца объяснять, что "переменная это ячейка в линейном адресном пространстве, для выделения которой используются вот такие очень страшные алгоритмы".
Если что, то у меня есть опыт обучения программированию.
Плюсую. Грамотный кодер ориентирован на решаемую задачу, а не на сам процесс программирования. И знание алгоритмов, которое есть следствие знания математики, это фундамент для любого более-менее серьезного кода. И мне смешно, когда троечники-школяры начинают меряться сиплюсплюсами, нахватавшись терминологии и скопипастив куски чужого кода из профильных форумов. Отсюда как следствие - засилие говнокода. И чтобы не пропадать зачаткам врожденной логики, зачастую и предлагают языки-кубики, чтобы из них можно было слепить полезный продукт. Любой гастарбайтер может сложить из кирпичей домик,но... рассчитать конструкции, оптимально подобрать материалы они не в состоянии.Нет знаний. Вот и клепают, либо с диким запасом, зря расходуя деньги, либо развалюхи, которые опасны для жизни. Без обид.
ну где вы были ))))
Знание алгоритмов есть следствие открытия спрааочника с алгоритмами. Во всяком случае, там, где пишется реальный полезный код. Математика э создагип этих алгоритмов - это совсем другип места и другип люди. Которым не нужно думать, что тут влезет с кэш, на что может заругаться антивирус и что не сумеют оптимизировать транслятор с asm .js и рантайм с текущих браузерах. То есть в it scientists саои задачи, у прикладников - свои.Для рассчёта конструкций никто в здравом уме тоже не лезет в физику. Берутся максимально подходящие готовые модели и подкручиваются, иначе вечно считать будете. Так и в it - берётся подходящая готовая алгоритмика с подходящей сложностью, а дальше (точнее, раньше) - решаются вопросы архитектуры, удобства тестирования, сопровождения, возможности быстрой демонстрации заказчику, удьбства ui и прочего. И этого "прочего" в любом сколько-нибудь сложном проекте куда больше, чем алгоритмических вопросов, и всё привязано к конкретным условиям.
Ваш "справочник" с алгоритмами называется Д. Кнут "Искусство программирования". И его "просто открыть" категорически недостаточно.
Развелось тут мамкиных копипастеров.И, пожалуйста, не смешивайте программирование, о котором разговор, и весь техпроцесс (включающий архитектуру, тестирование и т.п.).
у кнута не все вопросы разобраны. Развелось тут бородатых.
Берется книжка "Структуры данных в С++" У Топп = категорически не читается C++ код, а вот объяснение теории сложности алгоритмов там вполне не плохо.
Д.Кнутт - математик, если что. Вопросы разобраны не все. Ну и для грамотного использования алгоритмов, увы, знания тоже нужны. Но некоторым для "творчества" достаточно копипасты чужих примеров кода, а далее "методом Франкенштейна" прикручиваем недостающее. Если вы дадите неграмотному справочник по математике и попросите его решить парочку прикладных задачек, сами знаете результат. Вернее его отсутствие. И чем сложнее и масштабнее задачка - тем печальнее итоги. Индусские асы кодинга вам подтвердят.
Фунуциональщина как ролилась. так и жила в немёртаом виде. И по факту использоваться массово стала только а виде отдельных элеаентов, попавших в массовые языки, более пригодные для человеческих мозгов. В чистом виде как не использовалась широко, так и не используется. Вон, даже скала, которая гибрид, но с акцентом на функциональщину, из модв выходит.
А вот когда люди не понимают, что переменная - это просто ячейка в линейном пдресном пространстве, укпзатель - ровно такаяже ячейка, в которую положили номер первой, м вся семантика - это не более, чем наши фантазии, не играющие для машины роли - вот тогда и начинаются проблемы. Выделение памяти в этом контексте зачем бъяснять с деталях (ну, кроме стека) - я вообще не понимаю. Тема не тривиальная и не особо нужная, кто захочет - в книгах потом поглядит. А без него две недели там тратить не на что.
Баек про алгоритмизацию я уже наслушался. Не нужно в индустрии ничего кроме понятия сложности и умения его считать по известной сложности алгоритмов-кирпичиков, также как любой нормальный инженер за формулой лнзет с спрпвочник, а не выводит самостоятельно.
Фигню пишете.Скажите, какие проблемы у SQL разрабочиков, которые понятия зеленого не имеют, что такое "ячейка в линейном адресном пространстве"? А какие проблемы у джавистов, которые точно так же ничего не знают об указателях?
Особенно умиляет пассаж про "байки про алгоритмизацию". Сходите в МИТ, расскажите им, что они учат студентов байкам (если вы не в курсе, а вы ведь не в курсе, - они сначала год учатся алгоритмизации; причем раньше на лиспе, сейчас на питоне; и только через год переходят непосредственно к программированию как таковому и другим языкам в частности).
Упомянутое вами понятие сложности, всего лишь маааленькая часть алгоритмизации, а именно просто-напросто вычисляемая характеристика алгоритма.
>Упомянутое вами понятие сложности, всего лишь маааленькая часть алгоритмизации, а именно просто-напросто вычисляемая характеристика алгоритма.подкорректирую, сложность не вычисляется, а оценивается. В остальном - согласен.
> для системщины есть RustСпасибо, посмеялся.
слишком долго пишешь. Ушел бы через год на js - знал бы c++ в совершенстве ;-)
Оба хуже.
Рукалицо...
Вообще-то, "spaghetti code" - это не "рутина", а "запутанный или плохо структурированный код". (Это не опечатка, поэтому сам исправлять не стал)
spaghetti code -- это не рутина, это говнокод. Я бы исправил в новости, но не знаю как перевести на русский политкорректно. Макаронокод? Кодомакарона? Макодорона? Код-доширак? Или может тупо "запутанный код"?
лапшекод
если язык позволяет писать лапшу, то тут нет ничего "западлового"
у нас так и говорят - "макароны".
так ЯП это и есть тесто, а из него хоть рулетики (вкусняшки), да хоть и макароны лепи, оба съедобны (выполняются, и программа работает).
Нет. Макароны обычно выполняются довольно плохо, да и то только сразу после написания. После первого же апдейта начинаются проблемы в виде трудноуловимых и исправляемых багов.
нууу собственно по определению "съедобны" мы приняли, что он все же работает, а вот то, что вы имеете ввиду, то обычно, как принято говорить, "компилятор оптимизирует" ))), то есть желудок справиться если макароны были просрочены, или сорт муки третий и т. д. ;)
>Из проблем, мешающих работе лидирует некачественная документацияЭто в лучшем случае. Обычно вообще никакой ~~ложки~~ документации нет~~, приходится есть руками~~.
Source code is the ultimate manual :))
А где Dart/Flutter?Рейтинг ни о чем, какое-то легаси ...
Spring, React, Agular - рейтинг создавал кровавый режим Энтерпрайз Джавистов!
Из двух зол выбрали большее...
Чем больше рейтингов, тем меньше доверия. Особенно номинация "Среди языков, которые разработчики хотели бы изучить"....Либо надо возвращаться к практике брать разработчика под задачу, а язык/технологии не важны. Либо придём к тому, что "разработчики" будут изучать только то, что им нравится, а работать, собственно, будет некому....
> будут изучать только то, что им нравится, а работать, собственно, будет некомуА ещё эти мерзкие людишки идут учиться в универ на те специальности, которые они хотят, а работать на заводах, собственно, будет некому.
> работать на заводах, собственно, будет некому.Для этого нужны роботы.
Специальности в универе тоже не по желаниям абитурьентов делаются, а по потребностям отрасли. Если мы, конечно, не рассматриваем Курсерру, какую-нибудь.
А вот касаемо выбора технологий для разработки и внедрения, школьники, которые пошли в универ учиться, объективно не в состоянии сделать правильный выбор сами. Если все пойдут, например, питон изучать, то ИТ просто вымрет.
разработчики изучают то, что, с одной стороны, им нравится (или не вызывает раздражения, как минимум) и с другой - с их точки зрения даст возможность заработать (больше). Криминала в этом, хоть убей, не вижу.
> Криминала в этом, хоть убей, не вижу.Посмотрите внимательно на рейтинг. И ответьте на вопрос, сколько зарабатывающих на Haskell или Clojure разработчиков вы знаете. И, действительно ли, их в 2 раза больше, чем JS/Java/C-разработчиков?.... Также Scala, на которой никто в здравом уме сейчас новый проект не начнет. А процент пожелания высокой.
Смотри первый опрос - эту троицу и так куча народу знает. Логично, что люди хотят потыкать что-то новое для себя.Плюс хаскели, скалы и тому подобные, будучи адово бесполезными на практике в чистом виде, является очень приличным упражнением для мозгов и помогает использовать те элементы функциональщины, которые оказались полезными мейнстримных языках - начиная с банальных лямбд и заканчивая теми же плюсовыми шаблонами.
А в лидерах на изучение - как раз совершенно прагматически полезные языки.
>>будучи адово бесполезными на практике в чистом видекхмммммм, ну выкиньте из любого языка его стд либу, я посмотрю какая от него польза будет. Помимо этого, ни один из "райски полезных" языков не имеет место быть без ОС. Все практически языки - это формально обертки над системным API, не более.
>>А в лидерах на изучение - как раз совершенно прагматически полезные языки.
Современные ЯП - инструмент, извините но нафиг мне не сдался инструмент над которым еще нужно поломать голову, чтобы узнать как он работает, да еще не простреллить при этом себе ногу, в топ ку такой инструмент.
>>упражнением для мозгов
в топ ку такое упражнение, лучше бы заняться алгоритмическими проблемами.
>>даст возможность заработать (больше)им тогда не в Программисты, а в Предприниматели!
>>разработчики изучают
Разработчику (программному архитектору) - пофиг на все эти языки, ему достаточно бумаги и карандаша, чтобы начертить блок схему.
точно прикалываешься
кхмммм, задам такой вот вопрос, существует ли такой алгоритм, который можно реализовать только на языке допустим javascript? Если нет, то в чем прикол?
Да я о другом. Ну ясно же, что большинство разработчиков зарабатывают этим деньги. Понятно, что вопрос "где платят больше" их интересует.И просто "программных архитекторов", во-первых, мало (скорее, не бывает - те, кто проектирует, и код тоже пишут, и наоборот - все, кто прошёл дальше junior, не только кодят по указанию свыше, но и сами что-то проектируют в своей области ответственности), во-вторых - они тоже имеют свои языки/инструменты - UML и всё вокруг него, а отнюдь не блок-схемы на бумаге рисуют.
Что до ответа на вопрос - прикол в том, что помимо алгоритмов нужно учитывать среду. К примеру, в джаваскрипте если надо избавиться от дублирующихся значений можно можно это сделать руками, а можно - сунуть в объект и забрать оттуда все ключи через for. Вот лично я не знаю, что эффективнее, и ответ может меняться в зависимости от объёма данных, например. Для питона такие штуки запросто меняли время выполнения скрипта на порядок. В сях функция из пары тысяч строк при определённых обстоятельствах - вполне нормальный выбор. В джаваскрипте - это сильно ухудшит оптимизацию. И так далее, и тому подобное.
То есть как только мы выходим за вопросы алгоритмики и вспоминаем, что оно будет исполняться на реальном железе для реального пользователя в реальном рантайме или ОС - возникает масса нюансов. Временами напрочь перевешивающих любые соображения алгоритмики.
Плюс - есть скорость написания кода, сложность тестирования, доступность инструментов и т.п. И все компромиссы, с ними связанные, которые в блоксхеме не учтёшь. Вплоть до личных заморочек типа удобства отладчика.
Ну вот серьёзно - это ж всё совершенно очевидные вещи, неужели их надо разжёвывать?
>Понятно, что вопрос "где платят больше" их интересует.Я бы перефразировал бы - "Где меньше делаешь и больше получаешь", так вот я и акцентировал, идти нужно в предприниматели.
>И просто "программных архитекторов", во-первых, мало
Их ровно столько сколько появилось фронтендеров)), помните времена когда бекенд и фронтенд был на одной шее?
>во-вторых - они тоже имеют свои языки/инструменты - UML и всё вокруг него, а отнюдь не блок-схемы на бумаге рисуют.
все начинается с чистого листа (ц)
>Вот лично я не знаю, что эффективнее
а собственно в чем проблема? не знание? или не желание знать? зачем использовать инструмент который однозначно не гарантирует эффективность? Приведу самый тупой пример из мира пхп, что "быстрее" строки обрамленные одинарными или двойными кавычками? ))))) Кто-то воскликнет про "спички" и т.д. (забыли про эту тему). А вот, что касается про данные (объем), то тут нужно обратится к асимптотике, оценке, и соглашусь, будут алгоритмы допустим "быстрые" (временная сложность), но "жручие" по памяти (пространственная сложность) и на оборот, "золотая середина" тоже есть, и собственно идеальные.
>Плюс - есть скорость написания кода, сложность тестирования, доступность инструментов и т.п.))) хорошее уточнение "скорости" (скорость написания кода), не придраться.
>И все компромиссы, с ними связанные ....Обычно понятие компромисс относится к личному, в группе нет понятия компромисса, в группе один человек по идее должен волноваться за свою "шестеренку", и ваша мысль о компромиссах, скорости, эффективности и деньгах - не применима для группы.
Приведу пример, чтобы была ясна мысль, допустим я решил одним прекрасным днем написать собственную ОСь, так сел и начал думать, что я должен знать и сделать. Допустим надумал, что нужно знать "от и до" машинную архитектуру (хотя бы одну), продумать архитектуру ОС, придумать ЯП, и т.д. Потом прикинул сколько я затрачу на это сил и меня это отпугнуло, почему? Думаю ответ очевиден, - чего ради?
1) Бабло заработать? - не эффективно. Бабла ради, буду искать компромиссы, а ну нафиг свою ОСь писать, можно и существующую взять и заработать на ней. Так я быстрей заработаю. И это все относится только ко мне лично, я один обо всем думаю.
2) Если по фану, то - правильный ответ, этим должна заниматься группа. Разве Торвальдс не это имел ввиду?
Думаете он начал писать ОСь ради бабла? Почему он не начал с создания ЯП, а сразу начал писать ОСь на Си, и то не сразу ОСь, а сначала с миниксом поигрался. Похоливарил с Э. Т.
>Ну вот серьёзно - это ж всё совершенно очевидные вещи, неужели их надо разжёвывать?Человек идущий во всем на компромиссы, по вашему, очевидность? По мне, очевидно - человек стремящийся преодолевать трудности.
>>Понятно, что вопрос "где платят больше" их интересует.
> Я бы перефразировал бы - "Где меньше делаешь и больше получаешь", так
> вот я и акцентировал, идти нужно в предприниматели.а чем это принципиально отличается от "выбора инструмента, который гарпнтиркет эффективность?"
>>И просто "программных архитекторов", во-первых, мало
> Их ровно столько сколько появилось фронтендеров)), помните времена когда бекенд и фронтенд
> был на одной шее?Помню,-конечно, но а делу это не относится. Фронтэндер и проектирует, и код пишет, как и почти любой другой рпзрпботсик. И ссё - привязанное а совершенно конкретным условиям.
>>во-вторых - они тоже имеют свои языки/инструменты - UML и всё вокруг него, а отнюдь не блок-схемы на бумаге рисуют.
> все начинается с чистого листа (ц)ну давай сначала ещё этот лист делать и алфавит изобретать? Хочешь эффективности - пользуйся инструментами и ограничивай контекст применения.
>>Вот лично я не знаю, что эффективнее
> а собственно в чем проблема? не знание? или не желание знать? зачем
> использовать инструмент который однозначно не гарантирует эффективность?Не знаю, потому что джаваскрипт не знаю толком, тпм более современный. То, что я аидел с питоне, сильно зависит от объёма данных, причём как-то ломано и в доеументации про такое ничего нет. Я о том, что в любой сложной системе таких фокусов хватает, они важны
и совершенно не выводятся из "просто алгоритмики". И чем дальше - тем важнее, так каа сложность софта всё растёт.> Приведу самый
> тупой пример из мира пхп, что "быстрее" строки обрамленные одинарными или
> двойными кавычками? ))))) Кто-то воскликнет про "спички" и т.д. (забыли про
> эту тему). А вот, что касается про данные (объем), то тут
> нужно обратится к асимптотике, оценке, и соглашусь, будут алгоритмы допустим "быстрые"
> (временная сложность), но "жручие" по памяти (пространственная сложность) и на оборот,
> "золотая середина" тоже есть, и собственно идеальные.Оно так работает, когда есть ты и голая железка. И то - начинаются вопросы про кэш, производительность i/o и так далее. А когда есть рантайм, есть ос со своими фокусами (оверкоммит какой-нибудь) и прочее - единственный реалистичный подход - измерять. Я против оценки мложности совершенно ничего ге тмею, но это всё же простая модель, годная только для проствх случаев, которвх всё меньше.
>>Плюс - есть скорость написания кода, сложность тестирования, доступность инструментов и т.п.
> ))) хорошее уточнение "скорости" (скорость написания кода), не придраться.
>>И все компромиссы, с ними связанные ....
> Обычно понятие компромисс относится к личному, в группе нет понятия компромисса, в
> группе один человек по идее должен волноваться за свою "шестеренку", и
> ваша мысль о компромиссах, скорости, эффективности и деньгах - не применима
> для группы.Ну так шестерёнку можно тоже по-разному реализовать. И с разных проектах размер у них сильно разный. От отдельной фунции через рефакторинг модуля к отдельгой утилите.
А компромисс "время на разработку против времени на мануальное тестирование против написания автотестов" - он групповой, как и вопрос удобства тнх, кто иишет связанные модули или будет админить продукт. Валом таких компромиссов.
> Приведу пример, чтобы была ясна мысль, допустим я решил одним прекрасным днем
> написать собственную ОСь, так сел и начал думать, что я должен
> знать и сделать. Допустим надумал, что нужно знать "от и до"
> машинную архитектуру (хотя бы одну), продумать архитектуру ОС, придумать ЯП, и
> т.д. Потом прикинул сколько я затрачу на это сил и меня
> это отпугнуло, почему? Думаю ответ очевиден, - чего ради?
> 1) Бабло заработать? - не эффективно. Бабла ради, буду искать компромиссы, а
> ну нафиг свою ОСь писать, можно и существующую взять и заработать
> на ней. Так я быстрей заработаю. И это все относится только
> ко мне лично, я один обо всем думаю.Если конечная цель - решение конкретной задачи то тоже лучше существующую взять, как правило. Со всеми компромиссами, так как самому всё сделать - никаких сил не хватит.
> 2) Если по фану, то - правильный ответ, этим должна заниматься группа.
> Разве Торвальдс не это имел ввиду?
> Думаете он начал писать ОСь ради бабла? Почему он не начал с
> создания ЯП, а сразу начал писать ОСь на Си, и то
> не сразу ОСь, а сначала с миниксом поигрался. Похоливарил с Э.
> Т.У торвальдса, если я правильно помню, бабла на миникс не было, ну и фан, конечно. Сейчас тоже простенькую ось для МК можно взять и написать, даже в одно лицо. Но окажется, что для нынешних задач она слишком проста, к ней нет вагона готовых сторонних модулей, а времени потрачено столько, что ваш робот уже умел бы кучу всего если бы вы не изобретали велосипед. Опять же - либо компромиссы и что-то оабочее либо вечно пишем идеал, не дающий никакого практического выхлопа.
>>Ну вот серьёзно - это ж всё совершенно очевидные вещи, неужели их надо разжёвывать?
> Человек идущий во всем на компромиссы, по вашему, очевидность? По мне, очевидно
> - человек стремящийся преодолевать трудности.Мы всё ещё о мейнстримной (читай - коммерческой) разработке? Или о хобби?
>а чем это принципиально отличается от "выбора инструмента, который гарпнтиркет эффективность?"и как собственно выбрать эффективный инструмент не перепробовав все доступные ?
>ну давай сначала ещё этот лист делать и алфавит изобретать?
в предыдущих темах я одному анониму объяснил, что мастер - делает свой инструмент, и катается на своем велосипеде.
>Хочешь эффективности - пользуйся инструментами и ограничивай контекст применения.
комбайн против лопаты? контекст? - для того, чтобы вспахать один квадратный метр - лопата идеальный инструмент, для одного гектара - вероятно комбайн, а вот придумайте теперь мне инструмент который вспахает всю землю.
>что в любой сложной системе таких фокусов хватает
Зададимся вопросом, почему должно быть сложно? Разве дом построенный из обычно кирпича считается сложным?
>И чем дальше - тем важнее, так каа сложность софта всё растёт.
Какая именно сложность? Временная или пространственная? Любую сложность нужно преодолевать, в этом суть. Убил "время" человека, считай убил человека (ц)
>Я против оценки мложности совершенно ничего ге тмею, но это всё же простая модель, годная только для проствх случаев, которвх всё меньше.
ага, мы научились писать программы которые одну программу с одного ЯП переводит в другой ЯП, но не придумали программу которая за нас будет писать её, парадокс.
>Ну так шестерёнку можно тоже по-разному реализовать.Есть такие понятия как однозначность, единственность - и собственно любой алгоритм можно однозначным и единственным "эффективным со всех сторон" способом реализовать.
>И с разных проектах размер у них сильно разный. От отдельной фунции через рефакторинг модуля к отдельгой утилите.
Это все навеяно формализмом ЯП, будь один ЯП (асм), такого не было бы.
>Валом таких компромиссов.
А корней проблемы ?
>Если конечная цель - решение конкретной задачи то тоже лучше существующую взять, как правило. Со всеми компромиссами, так как самому всё сделать - никаких сил не хватит.
Повторюсь, в предыдущих темах по этому поводу я анониму объяснил, в чём разнича между "задачей" и "проблемой". Задачи - решают, так как существует метод их решения, а проблемы - разрешают, так как нет метода. Любая задача вытекает из разрешенной проблемы.
>к ней нет вагона готовых сторонних модулей
На все готовое
>Опять же - либо компромиссы и что-то оабочее либо вечно пишем идеал, не дающий никакого практического выхлопа.
Легко говорить про компромиссы когда есть варианты, в 70-ых бы почитать ваши коменты.
>Мы всё ещё о мейнстримной (читай - коммерческой) разработке? Или о хобби?
Ну определим сначала, что к чему влечет, мейнстрим к хобби, или хобби к мейнстриму. ))
Где Delphi?
Гусары, молчать!
Так паскаль вроде есть ...
будете смеяться, но вот буквально пару месяцов как пришлось реверсинженерить написанную на делфях аппликуху для андроида и выковыривать из нее протокол работы по BLE с популярным в узких кругах индустриальным девайсом, чтобы потом на микроконтроллере сделать. С согласия производителя девайса кстати, просто у них с тем разработчиками софта отношения такие веселые
Нахрен Жабу.. пора ее закапывать. И php тоже. Да вот только они на редкость живучие оказались.Я не говорю что js им будет заменой, нет конечно.. но есть другие более перспективные языки и для сервера и для системного программирования
А ещё php нужно закапывать как минимум по тому что пора писать приложения на фронтенде, с частичным обновлением страницы. А выстраивать html на сервере - должно уйти в прошлое
>пора писать приложения на фронтенде, с частичным обновлением страницы. А выстраивать html на сервере - должно уйти в прошлоеи так по кругу )))) как повашему зачем для всяких андроидов и айосов пишут апликейшены? зачем не мобильную версию сайта, а вот аппликейшен лучше. Ну давай те уже и для ПиСи писать сайты в виде аппликаций)))
> как повашему зачем для всяких андроидов и айосов пишут апликейшены? зачем не мобильную версию сайта, а вот аппликейшен лучше.Потому что юзерам удобнее/привлекательнее отдельную иконку и окно под условный твиттер, а не вкладку в браузере.
Как думаешь, почему возникли мобильные приложения на веб-технологиях? И растут. Потому что юзеру без разницы, на чём там написана приложуха. Если react-native приложуха тыкается, работает и жрёт подобно нейтив приложению, то юзера не волнует, что он юзает веб-сайт под видом приложения.
Вы не ответили на главный вопрос, зачем на ПиСи не так? Почему браузер (одна всего лишь программа) уже метит (точнее стал) на место ОС.
PC как правило работает не от аккумуляторов и имеет более мощный процессор и больше ram чем мобилки, что и позволяет всяким веб подделкам ну хоть как-то работать.
> PC как правило работает не от аккумуляторов и имеет более мощный процессор
> и больше ram чем мобилки, что и позволяет всяким веб подделкам
> ну хоть как-то работать.))))))))) убили
Оооооооой нет! Как ты не прав, дружище (в этих интернетах опять всякую чушь пишут, я им покажу!)React Native использует нативный only UI - слой, по сути внутри сидит тот же JSCore с интерпретатором. На Android-ах скорее всего V8. Поэтому неа, Native-приложения будут быстрее чем React Native.
Другое дело, что для бизнес-приложений его хватает. Но, что интересно, те же AirBnb, что топили за него, в итоге отказались и перешли обратно на Native. Почему? Почитайте их блог, если интересно.
React Native дает возможность набрать веб-макак (простите, "программистов" с улицы с бекграундом "знаю jQuery и слышал о JSX") и через 2-3 месяца путем подзатыльников вывести на определенный уровень скорости решения бизнес-задач.
Если мы говорим про высокопроизводительные (классные, хорошие такие) приложения для Native-платформ, то only Swift/Java.
Java со своей объектной моделью хороша для своей ниши - когда толпа индусов пишет код по дизайн-документам и под надзором белого господина из Калифорнии. Тут уже отработаны практики, позволяющие при такой организации работы получить вменяемый результат в разумные сроки. Более гибкие языки позволяют больше вольностей, которые полезны думающему разработчику с творческим мышлением, - но индуса мгновенно превращают в обезьяну с гранатой.Единственная адекватная замена - Kotlin, пожалуй.
пхп-то тут при чем?
частичное обновление страницы - это вопрос построения архитектуры приложения, а не языка. И что на замену? js? go? так там своих проблем не меньше.
Я имел в виду что пора бы чтоб клиент-сервер общались через апи, и сервер отдавал только данные.. Ну а так то да, go на бекенде. (С js на бекенде я не особо знаком)Если бекенд не компонует html - то уже куда меньше смыла использовать именно php, и можно использовать что-то более типизированное
кто сейчас мешает общаться через апи? как напишешь так и будет. при чем тут пхп? можно и на сях хтмл отдавать.ставь инклюды из аджакса и будет тебе счастье.
У php профит - ниииииизкий порог входа
GraphQL, пжлст
Как можно валить в одну кучу с одной стороны реакт и ангуляр, а с другой - спринг и асп? Это как бы клиентские и серверные технологии
Вангую, что на практике многие из ответивших, что "знают" JS, имеют только общее представление. А у Java порог вхождения выше
откройте рот! Так...закройте!
Не вижу патологии, мешающей вам тоже говорить что знаете java.
Проблема в том, что разработчики Java почему-то думают, что знают JavaScript, считая, что он императивный ООП-язык, а он больше функциональный, чем императивный.Отсюда получаются казусы, баги и черти что. А потом настрадавшись появляется TypeScript )
По информации из пункта приёма стеклотары, местные люди употребляют пепси-колу больше чем минеральную воду...
Сколько ангулярщиков-то развелось! Во всех смыслах ;)