Подробнее
^i|| \o\al
\_^\s'? $\лС\ 3
Pyrt-ioiO (A'y £ос<ЛсшМ Ik ^ I
"Зач/А
\' VYk 1’Сь\г>Л»Са\\'у f'jrvcTiOOft I •
ßüAWfock leHc^trscxWi. C 0<v\
"Rubчу er Сомрапюп "R <*.» W )
E-äUVNG»
6ш|й ^ 'г Точзь'Р» Ряо«л All ^У •р çlo Le^ -СИ рк) s
^ 11х?е J _OMier -f0>n a L,4 / ------- ~£>л»Ч Ык «A; It Ы-i^ you cou'J cL«6
языки программирования,программирование,python,R,java,javascript,brainfuck,haskell,много картинок,ruby,c++,C,C#,lua,lisp,matlab,Fortran,Rust,Go,erlang,Elixir,assembly,php,хуманизация,humanization
Еще на тему
В Германии Матлаб дает бесплатные лицензии очень многим универам, чтобы студенты привыкали к нему и потом работали уже с платными версиями.
Скажу, что когда меня брали на работу, то фирма использовала R, Python и VBA. Но начальник моего отдела выбрал меня из-за опыта в C и C++.
А вообще, фрилансить даже проффесионалам часто гиблое дело, заниматься этим любительски едва ли получится.
Для непосвященных: яваскрипт плох главным образом не тем, что он объемный в спецификации, не кучей идиотских легаси-правил, которые родились в войне за функциональность, которую комитет не смог вовремя родить. Хотя это все тоже добавляет. Но он уебищен по своей сути. Родившись глупым недоязычком с си-подобным синтаксисом (чисто для привлечения внимания, и слово java он содержит в тех же целях) он годами набирал костыли из "фич", которые уже лет 30 как не являются чем-то новым. Просто его основная аудитория это аутисты, которым нужна была анимация, и естественно через жопу, тупым обновлением "#id { top: "+y+"px; left:"+x+"px; }".
В итоге имеем лексический скопинг против глобал-объекта, лесенки колбеков против генераторов/корутин, тухлое ООП, которое когда не нужно, то ебет мозги, а когда нужно, то его просто нет. Тонны нюансов в поведении стандартной библиотеки, но такую штуку как leftpad приходится качать с левого сайта на свой страх и риск. PHP и тот менее больной, в нем хотя бы ЕСТЬ ВСЕ ИЗ КОРОБКИ.
И все, к чему сегодня "пришел" яваскрипт - это кривая реализация того, что уже было обкатано в десятке языков того времени. Хорошо у них получился только JIT, потому что если браузер не житит, то он автоматом сосет на рынке. При этом тот же LuaJIT засчет своей внутренней простоты с ним успешно соревнуется на стандартных тестах, хотя он не был установлен на КАЖДОМ компьютере и смартфоне в мире. Сегодня в обычном программировании существуют десятилетиями отточенные технологии, некоторым скоро век стукнет, но нет, они продолжают тащить это страшное уебище и свято верить, что современный веб это какое-то неебическое достижение. Нет, это технологический кошмар. Все, что выше HTTP[S], т.е. HTML, CSS, JS, JSON - для обычного программиста это полный зашквар, кроме разве что XML/XHR.
// java-кун
Для быстрого курса языковой и концептуальной терапии можно прочитать "Пионеры программирования".
PS: я еще хотел бы найти случай, в который опять таки попадал лично, когда одно и то же условие сравнения в ~половине случаев даёт true, в другой false; но пока не осилил
a) Долбоеб
б) Использует язык не по назначению
По поводу иммутабельности - вот тебе классический пример http://govnokod.ru/6312
Люди реально ваяют, игнорируя не только основные паттерны, соглашения по коду или стайлгайды, но и элементарный здравый смысл.
На код ревью пальцем тыкаешь, мол, чувак, так дело не пойдёт, это надо переделать, а он глазами хлопает, такой, типа "а чё, все же работает?".
Согласен, в языке масса странного поведения, но, если ознакомиться со спецификацией языка, то странности перестают быть таковыми.
Сейчас основными языкам являются java и js. На предыдущей работе были C++, питон и SQL(pgplSQL)
вот тут-то встают в полный рост недостатки и языков, и тулов, и методологии
вся хуйня стремится взгромоздиться друг на друга, а потом обрушиться на голову
Совершенно обычная ситуация, нормальная для любого более-менее крупного проекта, даже не обязательно связанного с программированием, и одна из причин, почему умные дяденьки давным-давно придумали всякие интересные штуки, вроде инкапсуляции и декомпозиции, а в программировании тот-же ООП и SOLID.
Другое дело, что в самом типичном случае люди на это кладут большой болт, а в результате:
> вся хуйня стремится взгромоздиться друг на друга, а потом обрушиться на голову
и это всё пришлось придумывать именно потому, что всё имеет тенденцию выходить из-под контроля по мере роста проекта
не класть болт сложно
не класть болт на код на говёном языке сложнее вдвойне
в этом и проявляется качество языков программирования. на более хороших проект не заваливается дольше, даже у команда не самых светлых голов
любой проект будет состоять минимум из нескольких составляющих (как правло - самостоятельных продуктов со своими тулзами и ЯП). Если, например, брать любую информационную систему, то там будет минимум две состаляющих - правильно выбранная (с учетом развития) для конкретных целей СУБД и грамотно смоделированная БД. Подавляющий % производительности будет зависеть от нее. Интерфейсная часть - да похуй на чем писать. Главное - выработать внутренний правила "грамматики" (регламент) и его придерживаться. и дрючить всех вокруг, чтоб писали по правилам (так же как, например, ты пишешь предложение на Русском языке придерживаясь определенных правил). Все. Нужно правильно подбирать инструменты для работы. Вот для этого и нужны знания тех умных дяденек, которые напридумывали этих ваших языков. Каждый из которых работал в определенной прикладной области, т.к. любая универсальность - это жирный минус к производительности. Ибо - избыточность.
По этому, чтоб бардака не было нужно ПЛАНИРОВАТЬ, блять, а не хуячить по принципу - этот ЯП охуенен и мне нравится, давай на нем ебашить.
И потом начинают вместо SQL хуячить SP с перебором строк в цикле.
Каждый ЯП имеет область применения в которой он хорош.
Если ты откроешь любую книжку по СУБД, напримр, то прочтешь, что в любом проекте обязательно должен быть 1 архитектор. Если их больше 1 - хуйня полная будет. Только категории мышления у него должны быть другие. Это у нас повелось издревле - 1 чел целиком делает проект (от погружения в предметную область, до написания кода и еще техподдержки).
Помню, был период, когда было одновременно 5 проектов.. это пиздец. В итоге, толком ни один не двигался. Хуита короч. У нас же все хотят "сократить расходы".. ебланы.
эт последние лет 5-7 стали более менее вмыкать что к чему. да и то.
похуй, на чем писать - похуй, что писать - похуй как - похуй, кто разгребать будет
языки разные
даже если преположить, что есть уникумы, которые хуячат код на чем угодно одинаково хорошо, я таких не видел, ожидать, что такими в команде будут все - глупо
нужно знать инструменты, знать тулзы, знать либы, экосистему
иначе будет код на руби с сотнями фабрик, как на яве, и тому подобная хуйня, или попытки руками менеджить объекты в яве, как в сях
сотни костылей, сотни утилей, вместо библиотечных функций
просто потому, что кто-то думает о себе дохуя, типа он такой молодец, что налабает на любом языке хорошо. обычно от таких самый говнокод
Системный подход и стандартизация рулят. вот об этом я писал выше. чем и как - вопрос не первой важности.
стандартизация чего? кода на совершенно разных языках? ну на некоторые языки есть стандарты, что будет кодом на этом языке, что нет. но что при этом будет хорошим кодом на этом языке - покажи мне такой стандарт!
и как вообще человек, который даже не пробует разобраться в отличиях используемых им инструментов - они для него все одинаковые - наваять хоть что-то хорошее? для меня ясно, что писать на одном языке как на другом - получить плохой код.
и сами языки по качеству я тоже различаю. на скриптовом за серьёзный рефакторинг я, скорее, не возьмусь, проще переписать с нуля, на статически типированном недавно занимался - гемор, но не смертельно. хотя бы это жирнейшее различие надо видеть!
а какой там порядок или беспорядок у кого в голове - там пусть и остаётся. лучше, когда язык ограничивает возможность выплеснуть свой богатый внутренний мир на окружающих. ну и плюс всякие техники по сдерживанию такого поведения, типа ревью, тоже помогают. но лучше, конечно, когда сам человек понимает, что его код будут читать другие люди и пишет его соответственно
Значит возможна и обратная операция - улучшение языков. Во всем пространстве возможных языков явно можно двигаться в сторону оптимизации некоторых параметров.
Если языки из одной ниши, то можно их сравнивать напрямую, если из разных - с учетом задачи.
К этим тезисам, надеюсь, возражений нет?
какая-нибудь сборка мебели на конвейере (это абстрактный пример).
по конвейеру движутся определенные узлы конструкции и в каждой точке происходит какое-то действие. каждое такое действие выполняется определенными инструментами и специалистами и в строго определенном порядке. Например, если залакировать и покрасить элементы до их сборки с применением гвоздей и молотка, то придет пиздец всей лакировке.
Или, если сколотить каркас, а потом пытаться вырезать рисунок - высока вероятность того, что каркас сломается или к каким-то его элементам будет закрыт доступ.
далее. каждая единица мебели стоит денег (материалы, работа, амортизация станков\инструментов) и т.д. на одном из узлов происходит сборка конструкции (например прибивание какой-нибудь защитной панели). Для этого используются гвозди и молотки. Они целиком и полностью выполняют свою функцию как с точки зрения требований, так и с точки зрения временных затрат и финансовых затрат (стоимость сотрудника и стоимость инструмента).
Если ты решил вместо молотка купить универсального, робота, который и шить и колотить и пирожки печь умеет. То ты нихуя не окупишь его используя на этой низкоквалифицированной операции. Это затраты на: оборудование, обучение персонала, з\п для этого персонала (высококвалифицированный спец дорого стоит), обслуживание и т.д.
Так вот. С точки зрения производственной эффективности - твоя покупка буде нихуя не рентабельной.
А если сказать чуваку. Вот молоток и гвозди. Колоти сюда и сюда за такое то время. Все будет заебись. При том, что такой сотрудник оч хорошо заменяем. Потому что - его процедура стандартизирована (!).
Если такой сотрудник начнет нести хуйню, мол вы не те гвозди используете. Вот, есть супер продвинутые гвозди самозабивающиеся, да и молоки есть пневмо, то ты, оценив с точки зрения здравого смысла такие выверты тупо шлешь его подальше и берешь другого. Который тут же начинает по той же самой, стандартизированной схеме хуячить гвозди в деревяшку.
Результат - продукт есть? Есть. Мощностей молока и чувака хватает, чтоб обеспечить работу конвейера? Хватает.
В этом и ответ - каждый инструмент хорош на своем месте. В области своего применения.
Никого, блять, не интересуют псевдонаучнофилософофильские измышления о том, где же идеал в производственном процессе. Этим можно побаловаться на досуге.
Так и в написании ПО. Это тот же конвейер. Где задействованы (хочешь ты или не хочешь) абсолютно разные инструменты. Вопрос не в гипотетических возможностях "грабить корованы" ЯП, а в том, на сколько они удовлетворяют критериям того или иного проекта. Сделать выбор, утвердить правила и план работ и выполнять его.
вы ты пишешь "Сделать выбор, утвердить правила и план работ и выполнять его." а как делать этот выбор? от балды? потому что технология дедовская проверенная, или потому что модная и клёвая, или потому что техлид недавно на конференцию по ней ездил, или потому что кадры есть?
язык - тот же инструмент, их надо уметь выбирать
особенно актуально это в моей области, я не столяр, я программист, мне не надо станок за миллиард покупать, мне надо всего-то скачать софт и маны покурить
И от того, какой инструмент будет выбран - будет зависеть, сколько еще будет их потрачено.
Сказки про "покурить" слушано переслушано. Как правило все заканчивалось все жопой. то оказывается одно не дочитали, то другое не досмотрели, а тут все криво реализовано, а вот тут из мануалов - только перечисление функций, а эту библиотеку я перепишу и т.д. и т.п.
для того, чтобы делать выбор - нужно мочь сравнивать. для того, чтобы сравнивать - нужны эмпирические данные. чтобы получить эти данные нужно поработать с разными ЯП самому, или видеть, как реализуются проекты на нем (есть ли достаточное количество спецов, сколько времени займет вхождение и т.п.)
и самый первый шаг - это планирование, разработка арихтектуры и понимание - что будет, в каком виде и за сколько денег.
ты мыслишь очень узко - парой языков программирования. надо учиться шире охватывать. вот по этому, кстати, и не можешь "уместить в голове" проект.
это, если б художник мыслил только фактурой красок и кистей или композитор - звучанием одного - двух инструментов.
что вообще пох, на чем писать, лишь бы содержимое головы было... хз какое, ты мне так и не рассказал - это не мой тезис :)
твой тезис - он о чем? о субъективном восприятии объективной реальности? о том, что процесс оптимизации - вечен?
понимаешь. ты говоришь - зачем эти детские аналогии. затем, что ты начинаешь скатываться все время в конкретику. вместо попытки объективного анализа у тебя получается сравнение конкретной строк.
конечно пох на чем писать - если ты умеешь это делать одинаково хорошо на разных ЯП. Классический пример Hello World
http://italyanec.livejournal.com/110223.html
объясню. все из перечисленных примеров выполняют функцию вывода строки на экран.
теперь - надо понимать кому и как она должна выводиться. разработчику, с доступом к БД или анонимусу через веб или админу в консоли или чуваку в 1С-ке или юзеру в толстом клиенте, а может нескольким из них или всем сразу?
а если надо, например, сделать доступным для удаленных юзеров с узкими каналами, а твой, какой-нибудь мегакрасивый, новомодный язык посылает хуеву тучу мегабайт бесполезных данных при обмене с БД или вообще на нем можно писать только толстого клиента.
а если при этом у юзеров есть ограничения по устанавливаемому софту и кроме IE8 у них ничего не стоит и монитор с разрешением 1024х768? И такой хуйни на самом деле полным полно.
И ты - такой гордый, что вот, написал супер красивый код. И служба сопровождения - охуевающая от жалоб пользователей, что что-то в экран не влезает, то коннект отваливается, то, блять, эргономика такая, что хочется взять и уебать.
Вы, ваще зажрались...привыкли к широкоплосному интернету, хорошим компам, большим мониторам и т.д.
древняя, как говно мамонта отмазка "у меня же работает" - полная хуйня.
О пользователях надо думать, и об условиях эксплуатации и цене и времени вопроса при выборе инструмента, а не о том, какой он красивый и быстрый и что мне очень удобно в нем работать.
Быстрый Бентли по нашим дорогам - разъебется вхлам сразу вместе с юзером за рулем.
А профи на то и профи, что может все и на всем. Любого профессионал и является им по той простой причине, что в его руках все делается с приемлемым качеством и вовремя.
Заткнись и хуячь, на чем дают, солнце еще высоко.
И это всё ложные и вредные убеждения.
Да, им пофиг. Но мы-то инженеры, это наша зона ответственности. И нам с этим жить.
Если код превратился в такое говно, что в него даже лезть не хочется - это наша вина. Мы должны понимать, что без должной дисциплины, без методологии, без постоянного рефакторинга, без тестов/инвариантов - так оно и будет, неизбежно. И если мы нифига не делаем, чтоб этого не было - то мы мудаки.
Можно, конечно, налабать говна и свалить в другую контору, но потом всё-равно кому-то это разгребать.
Некоторые думают, типа пока проект еще не разросся - пофиг, как его делать, мож мы его выкинем завтра. Но когда он вдруг стал нужен, стал расти - уже поздновато бывает чота делать. И требований сразу много возникает, и фичей сразу все хотят, и совсем не до рефакторинга и переделок, а менять что-то уже сложно.
Проект уже легаси еще едва родившись.
На небольших проектах как раз можно повнедрять нужные методологии, привыкнуть, обкатать.
От команды всё зависит, и если она не юзает правильные методологии и надеется, что когда понадобится - так сразу возьмут и начнут - хер там, они мудаки и слишком дохуя о себе думают.
Гораздо сложнее внедрять правильный подход в живой большой проект. И ни бизнес, ни юзеры этому рады не будут.
Сразу надо. Всегда. Постоянно. Тогда будет проект нормального человека, а не проект курильщика.
Ну и то же самое про языки. Их надо знать, и не только уметь на них налабать хелловорлд, а знать их историю, зачем их делали, какие проблемы решали, почему так, а не иначе; знать мету, знать классификацию, знать теорию.
Иначе в один прекрасный момент поймешь, что жизнь говно, ты каждый день заныриваешь в говно, ненавидишь всё это. И с завистью смотришь на проекты нормальных людей, на красивый понятный код, и не понимаешь, вроде не полубоги его делали, и время у них не в разы больше уходит, и фичи они стабильно выдают, как так-то бля?
Зачем делать это себе и окружающим?
И бизнес и пользователи в итоге-то тоже пострадают, останутся в итоге на полудохлом легаси, в которое одну фигу добавляешь - 3 ломается.
И профи не в том, что может лабать говно, а может не лабать. А в том, что предотвращает долгоиграющие последствия сиюминутных стремлений срезать углы, на то он и профи, новички хуячить код тоже могут, а когда уткнуться в жопу, разведут руками
исходный посыл "пох на чем писать" в моем субъективном восприятии интерпретируется с той точки зрения, что не всегда мне доводилось писать с нуля какие-то проекты. как правило - это включение в уже имеющиеся с соответственным "наследием" и необходимостью дальнейшего расширения функционала и (боже упаси) интеграции с другими системами. и тут уж приходится либо - умыть руки и сказать "ебитесь сами", либо пытаться в меру своих сил привести в какой-то, возможный на данном этапе порядок, либо забить и ебошить говнокод.
а порядок - это системный подход и к выбору направления, погружение в предметную область и просчет вариантов развития и выбор языка(ов) и выбор систем окружения и т.д. и т.п. и в конечном счете это тот самый "красивый код" (а он может быть красивым практически на любом языке) которым должны писать все.
Тогда и в голове будет порядок и в коде. И не важно, какой будет объем проекта. Если ты знаешь правила. Ведь не важно в каком населенном пункте какой страны ты едешь. ПДД на 99% везде одинаковые.
рад, что обознался, и что мы, вроде как, достигли взаимопонимания
Очень забавно, порой, наблюдать как молодежь пытается выяснить у кого код длинее.
интерфейсную и серверную части я переписал с нуля. А вот то, что находится в хранимых процедурах - это, блять, даж не знаю, как назвать.
Каюсь, сам не без греха... уж лет 7-8 назад тож пытался извернуться и сваять конструктор. Оправданием может служить только то, что тупо на нормальный анализ и доработку был уже не в силах сделать, т.к. все время уходило на одновременную работу над 5 проектами.
https://www.destroyallsoftware.com/talks/wat
В сравнении с тем что может js - у всех остальных просто таки очень большая нехватка подобного, прямо таки огромная. А уж если еще учесть популярность и распространённость самого языка - тогда еще грустнее.
Но почему то никто из хейтеров не хочет задуматься, почему так вышло.
А по поводу других ЯП в браузерах: существуют трансляторы из разных языков в JS. Даже из Си есть. А если нет необходимого транслятора, так напиши сам, раз в спеках шаришь. А еще скоро WebAssembly подвезут, так вообще заживем (хотя это к JS уже не особо относится)
математика над поинтерами во все поля
и они предлагают эту херню мне в свой браузер пускать напрямую?
да ну нахер
если песочницу выделять под wasm - межпроцессный интероп не бесплатен.
собрались крупные компании, запилили стандарт, их-то код юзеры всяко будут пускать в свои браузеры, тк репутация и доверие. а мелкие конторы могут неиллюзорно соснуть
так что хуй знает, кто заживёт, а кто нет.
а могли бы делать так, чтоб этот код был сильно более дружелюбен к статическому анализу и верификации, что он херни не делает, до выполнения
А еще через несколько языков ты поймешь, что разные парадигмы не ложатся друг на друга без потерь, и если ты транслируешь одно в другое, то это тот же хуй, только в другой руке, а не проброс концепций.
Вебассембли теоретически может исправить ситуацию, его и ждем.
Понятное дело, что нет универсального ЯП. На данный момент js - это единственный язык нативно поддерживаемый браузерами. Создавался он именно как скриптовый язык, т.е. предназначенный для того, чтобы пилить костыли и всякие фишечки на вебстраничках. О жирных одностраничных вебприложениях и 3D-играх прямо в браузере на момент создания этого языка и речи не было. Тогда говорили, "если у вас что-то не получается сделать при помощи html-верстки и css, используйте js". Производителей браузеров несколько, а сайтики должны открываться в любом. Это естественным образом привело к стандартизации js. Стандарт он на то и стандарт, чтобы не меняться как можно дольше. Однако со временем оказалось, что js уже вырос из своих "скриптовых" задач. Но стандарт есть стандарт. Поэтому в js можно только добавлять, а убирать крайне затруднительно. Отсюда некоторая монструозность языка. От него хотят всего, но ведь универсального средства нет. Оттого и волна хейта.
Вебассембли даст нам, грубо говоря, процессор в песочнице. Но непосредственно на этом низкоуровневом императивном языке вряд ли кто будет писать. Вместо это будут многочисленные компиляторы и трансляторы из различных ЯП, относящихся к совершенно различным парадигмам, в этот, я повторюсь, ИМПЕРАТИВНЫЙ ассемблерный язык.
Нисколько не сомневался, что получу такой ответ. Если в экосистеме js - самый развитый в плане поддерживаемых подходов, то это очевидно так. А если нет, то совсем неочевидно, отсюда ложная уверенность. The Blub Paradox. Я могу перечислить хотя бы неполноценный лексический скопинг, отсутствие окружений и взаимодействия с коллектором, для примера и понятного минимума, но вдаваться в детали не охота.
Строго говоря, моя критика не в том, что из js что-то не убирают, мне все равно, что будет с этой помойкой. Критика в том, что есть несколько ГОТОВЫХ и проверенных временем решений, которые можно просто включить в браузер без изменений и получить, условно говоря, аналог ECMA-262 2030 года в лучшем его виде.
>Вебассембли даст нам, грубо говоря, процессор в песочнице. Но непосредственно на этом низкоуровневом императивном языке вряд ли кто будет писать.
А зачем на нем писать? Это как раз тот условный bare metal, на котором ничего не происходит само, и ты волен реализовывать вещи так, как они нужны, т.е. это обычный таргет бакэнда любого компилятора. В этом и суть, что там нет навязанной модели исполнения, и одновременно с этим это не тормозная симуляция виртуальной машины на яваскрипте.
Еще несколько вопросов: В чем проявляется неполноценность лексического замыкания в js? Что подразумевается под "отсутствием окружения"?
Еще очень интересно, какие по твоему мнению готовые и проверенные решения следует включить в браузер?
Все так же, как ребенок обучается языку общения. Сначала простые слова с привязкой к простым действиям, потом более сложные и т.д.
Ну и без шуток. Мне еще никто не смог мне сказать, как гугл смог повлиять на популяризацию Go. Показывали его рекламу в адводсе?
ну и репутация гугла роляет