All streams
Search
Write a publication
Pull to refresh
28
0
16tomatotonns @16tomatotonns

Lua, python, прочие скрипты, сишка. Чутка GLSL.

Send message
«Высокоуровневый проприетарный проект» означает «кучу правок разных людей во время дедлайнов», там совершенно нормально писать хромоногие химеры. Потом отрефакторят. Или нет.
Игровой фреймворк love2d использует технологию аналогичную rarjpeg: в конец исполняемого файла просто подшивается архив с ресурсами игры, и при исполнении, открывает сам себя как архив, выуживая оттуда main-скрипт как точку входа, попутно монтируя себя в качестве корневого каталога местной виртуальной ФС.
Читалкам архивов всё равно, что в начале исполняемого файла есть какие-то байты, он ищет заголовок архива и начинает работать с ним.
В языках с худо-бедно строгой типизацией, будут ошибки вроде «невозможно сложить число с массивом», когда извне приходит не то что ожидалось, и из-за этого может вылезать гора ошибок. И вот из-за этого некоторые ребята называют жаваскрипт дурацким, потому что при беглом прогоне как бы должна была выскочить ошибка, а её не было, всё как бы нормально, потом ошибка идёт дальше неотловленной.
Это только одно из мнений, их множество.
Ruby! Какой глупый язык.
Clojure! Какой глупый язык.
Haskell! Какой глупый язык.

Я не видел ни одного «wtf js?!» с демонстрациями вида «0.1 + 0.2 != 0.3», потому что это довольно общеизвестная проблема среди большинства языков. С этим сталкиваются практически все в любой арифметике (за исключением отдельных математических движков вроде numpy/wolfram-mathematica, которые профессионально умеют вплоть до натуральных дробей), поэтому или принудительно округляют числа до какого-то знака перед прямым сравнением, или сравнивают их исключительно на «больше-меньше».

Некоторые ребята называют JS глупым языком из-за странных автоматических приведений типов, вроде
0 == [] //> true
//но
[] == ![] //> true
// и
10 + "20" //> "1020"
10 - "20" //> -10
10 + [1, 2] //> "101,2"
10 - [1, 2] //> NaN

По неочевидному поведению this, и ещё по нескольким причинам, как правило, приводящим к выстрелам в ногу на пустом месте, пока не выучишь конкретное поведение конкретной фигнюшки во всех возможных комбинациях, зато потом будешь ими хакать и взрывать мозги окружающим.

А по плавающей запятой претензий что-то не видно. Если кто-то называет язык глупым по подобной причине, его можно смело, вообще без каких либо вопросов, гнать учить машинные представления чисел, до просветления. Или(!) даже заставить его выучить хотя бы один, любой, популярный язык: подобные претензии явно указывают, что оратор вообще не понимает о чём говорит и принципиально ничем не владеет. Вот ещё, на громких неучей срываться, и писать для них статьи, метать перед ними бисер. Они же даже не попытаются научиться, да и у них глобально другая цель: обозвать что-то «глупым», возвышая себя над целым комьюнити «тупиц, которые пишут на своём глупом языке».
В таком случае да, придётся что-то делать.
Например, вот что придумалось:
У нас есть смещение до цифр первого ключа. После него, ищем ближайший пробел, вырезаем полученную подстроку с цифрами, и прибавляем к нему смещение до следующего ключа, вроде:
let line = "Buffers: shared hit=12345 read=456 local hit=789012"
let a = 21 // длина "Buffers: shared hit="
let b = line.indexOf(" ", a) - 1 // позиция пробела, т.е. конец цифр
let shared_hit = line.substring(a, b).parseInt()
a = b + 6 // длина " read="
b = line.indexOf(" ", a) - 1
let shared_read = line.substring(a, b).parseInt()
...


Технически должно быть быстрее всего, хоть и весьма по-индусски/китайски. И я не уверен что обгонит сишные регулярные выражения, с другой стороны может быть заJITуется. Конкретные цифры смещений опять таки можно вычислить заранее и закешировать.
При надлежащем форматировании исходных строк, можно остановиться на обыкновенных substring'ах.
Форматируем наши строки в
Buffers: shared hit=00123 read=00456, local hit=00789 (ограничивая диапазон значений), но зато мы точно знаем что можно сделать так:
obj = {
  "shared-hit": line.substring(21, 26).parseInt(),
  "shared-read": line.substring(32, 37).parseInt(),
  "local-hit": line.substring(49, 54).parseInt()
}

Разумеется, конкретные цифры можно найти регулярным выражением и закешировать, многократно переиспользуя.
Данный вариант должен оказаться наиболее быстрым из возможных, требующим наименьшее количество дополнительной памяти.

Когда сам занимался наиболее быстрым парсингом, пришёл к заключению, что наиболее эффективными оказываются фиксированные длины, без какого либо парсинга и регулярных выражений.
Ну вот да, если использовать http-заголовки «для всего» — совершенно непонятно, на каком слое абстракций произошла проблема. Допустим, сервер прислал 500 ошибку. Что же это может быть?
1. Нас отфутболил балансировщик;
2. Упала какая-то нода;
3. Упала какая-нибудь очередь сообщений;
4. Упал конкретный целевой сервис;
Где искать проблему? По сопроводительному тексту? А надо ли выдавать пользователю трейсы конкретного сервиса? (нет, нельзя, коммерческая тайна и весь фарш)

По ответу вида
HTTP:200 {
  "service": "myservice",
  "datetime": "22.22.2222 22:22:22",
  "status": "SERVICE_ERROR",
  "response": {}
}

Хотя бы понятно где локализована проблема, нет необходимости перерывать лишние гигабайты логов (и хорошо если логи в одном месте). Хотя это очень не нравится фронтовикам, которым очень хочется написать один единственный обработчик всех ошибок вида if (status != 200) {}.

Вся задача вывода этих статусов/ошибок/кодов — выдать максимум информации для облегчения отладки, в наименее полезной для потенциальных хацкеров виде. Одним статусом не ограничишься.
Стим, помимо, собственно, продажи, выполняет ещё несколько вещей:
— Автоматически решает здоровую часть юридических проблем, платит налоги за разработчика и далее по списку;
— Рекламирует, советует и так далее (выполняет роль торговой площадки);
— Хранит и раздаёт копию игры, автоматически обновляет и патчит, предоставляет набор вспомогательных сервисов: аддоны, ачивки, соединение игроков в лобби (nat pushing), мастерская, торговая площадка, свистелки и колокольчики, которые разработчику пришлось бы реализовать самостоятельно и платить за это дополнительные деньги ежемесячно (хранение и хостинг мастер-серверов).
EGS, который требует снижения ставок, предоставляет часть сервисов, но совсем не решает налогово-юридические проблемы, они остаются на совести разработчика, и при пользовании их площадкой и полном отсутствии проблем, общий доход разработчика, в зависимости от законодательства его страны, имеет приблизительно ~10% разброс прибыли в сравнении со стимом.
Информация не полностью точная, со слов моих знакомых, релизящихся и там и там, я бы её ещё раз проверил.
Автор того комментария почему-то приравнивает веб-верстальщиков и кнопкорисователей клиентских частей (в которые как раз выбиваются те которые «в айти >35») к рокстарам, которые толкают computer science и как раз обладают соответствующими зп.
собеседования в Гугл, который делает самый прожорливый браузер, — так и вообще притча по языцех.

Гугл, к вашему сведенью, помимо разработки браузеров, занимается множеством вещей. Те вещи, которые требуют сверхвысшего образования (в основном, матан) там действительно имеют достаточно крутые собеседования. Но я упомянул ещё в первом комментарии: "Причём виновен не только сам браузер, который как самый умный кеширует даже то что не просили", и уточнил конкретные проблемы всестороннего кеширования: оно жрёт. В целом, по сервисам, у гугла весьма техничные вещи, в нём в целом думают головой, башка выглядит совсем отрубленной у подавляющего числа тех, кто пользуется их браузером как инструментом и разрабатывает для него.

Сайтовый фронтенд принципиально выглядит как будто там никого ничто не заботит, пока картинка выглядит красиво. И боюсь что основную часть фронта делают не «синьоры с 300ккк/сек» а максимально дешёвые ребята (да-да, даже в сбербанке) за максимально короткие сроки (да-да, в альфе тоже, и в МТС, никто не будет таскать профессоров на реализацию аяксов и рисование кнопочек, но что-то притаскиваются почему-то совсем «успешные успехи»), я лично знаю нескольких людей которые продолжают там ваять, они… Не очень понимают что делают, но умеют в красивые картинки по тз.

Предлагаете прочекать вакансии?
Альфа-банк: зарплаты не указаны, даже намёка нет (=будут торговаться до последнего), требований — минимум «хотим жс/цсс/хтмл/хттп и пару модных фреймворков», сомневаюсь что там будут проверять что человек в принципе умеет программировать вне рамок фреймворков;
Сбербанк: зарплаты не указаны;
МТС: зарплаты в IT не указаны, разброс по остальным вакансиям — 40-120к;
Вышки, тем более технической, в требованиях что-то тоже не особо видно.
Яндекс при мне выдавал достаточно сообразительным джунам с вышкой 120к со старта в 14 году, вот только «сообразительность» и «знание своих инструментов» — это сильно разные, не пересекающиеся между собой вещи, плюс этих ребят не сажают за вёрстку и жаваскрипт-сопровождение.
Но дело даже не в этом :)

то, на что вы так жалуетесь, есть «продукт жизнедеятельности» самых лучших и высокооплачиваемых разработчиков мира

Ну, вы можете верить во всё что угодно, я вижу несколько иную картину.
Каких-то десять-пятнадцать лет назад люди почему-то писали и рисовали ровно то же самое, пользуясь надёжными дедулькиными методиками, и куда менее затратно по ресурсам. Вы видели операционную систему Symbian и ттх телефонов с ним? Да, оно притормаживало в сравнении с топовыми смартфонами сегодняшних лет. Но там и было 100-200мгц и 1-16мб ram.
Я хотел бы, чтобы подобные вещи были написаны с применением здравого смысла и хоть какой-то заботы о конечном пользователе, а не это вот. Это не очень сложно даже с использующимися инструментами. Для этого не нужно быть профессором, для этого не нужно быть высокооплачиваемым рокстаром, достаточно просто не следовать модной моде и успешному успеху, а хотя бы примерно знать свой инструмент и чуть-чуть задумываться головой. Если мастер владеет своим инструментом исключительно на уровне модных трюков, и может выполнять только их, игнорируя, собственно, работу — это не мастер, это трюкач. И грош ему цена, когда нужно сделать что-то кроме трюков, хотя трюки очень впечатляющие, я согласен (смотрите, я решил эту задачу в модном стиле с иммутабельностью, её можно параллелить на тысячи потоков, не знаю как, но как-то точно можно, мне так рассказали).

Вы задумывались когда-нибудь, почему школьная программа по математике составлена именно так, как составлена? Почему первые четыре класса идёт обучение в основном арифметике, почему дальше вводятся сложности (неизвестные переменные, тригонометрия, степени, сокращённое умножение, простая линейная алгебра и т.д.) и почему простые варианты функана под конец? Почему бы в первом классе, сразу после сложения и вычитания, не дать функциональный анализ с тригонометрией, а дальше как пойдёт под предлогом «там же всё очевидно»? Почему такая схема отлично работает у новых модных программистов, которые конечно «не профессоры», но «успешные ребята на разработке клиентского софта»?

> Таки вы точно уверены, что именно в них проблема с плохими приложениями?
Да, да, а ещё можно перевесить стрелки на пользователей: «они же и так схавают, так зачем стараться, тратить время и вообще задумываться?», и они-то схавают, не подавятся и обновят технику, потому что альтернатив нет :)

> в «продукты жизнедеятельности» вайтишников и крудошлепов вы никогда, скорее всего, и не вступите
Очень интересная гипотеза, у неё есть какие-то основания? Я продемонстрировал обратное, по поводу фронтенда, в своём предыдущем комментарии, вам есть что-то сказать по этому поводу?
Лично меня сильно раздражает то, что в результаты жизнедеятельности подобных, кхм, мастеров мы регулярно встреваем лично. Приведу несколько примеров:
— Для простейших, элементарных приложений на android МТС и Сбербанк (ещё несколько приложений Яндекса, хотя они сложнее но незначительно), единственная задача которых — делать асинхронные запросики и показывать кнопочки со статичными картинками, уже мало двух гигабайт оперативной памяти и двух ядер. Нужно минимум четыре гига-четыре ядра, чтобы работало без кошмарных тормозов и вылетаний при полностью чистой системе.
— Браузеры потребляют очень много оперативки. Причём виновен не только сам браузер, который как самый умный кеширует даже то что не просили, но и умные модные сайтописатели, использующие очень модные функциональные подходы. В результате, под модные современные иммутабельные мусорные объекты размечается очень много памяти (а потом ещё пара десятков цепочек генерации новых иммутабельных объектов вместо старых, старые же можно тут же выбрасывать), которая потом «когда-нибудь» освободится. Или нет. Вкладка браузера с этим постом занимает 80 мегабайт и растёт при попытках поскроллить вверх-вниз. Если бы тут было чуть больше комментариев, она разрослась бы на все 200-500мб. Это… Ужасно, на самом деле. Скорость разработки и модные (дорогие по памяти) красивости оказываются значительно приоритетнее практичности и хоть какой-то экономичности.
— Редакторы кода. Простые редакторы, на основе CEF/Chromium. На них очень здорово клепать жаваскриптовые плагины. И всё. Молчу про время загрузки, про время операций поиска/замены текста, про время между нажатием клавиши и непосредственным отображением введённого символа (оно плавает и ныряет), про халтурные, наивные, написанные на неподходящих инструментах системы автодополнения и парсинга (замашки в сторону IDE). Складывается впечатление, будто их создавали в качестве Самого Главного Приложения для кручения на мейнфрейме. В ту же сторону мессенджеры вроде Skype/Discord. А ещё они хорошенько текут и не живут без перезапуска дольше недели (до месяца на мейнфрейме, прост за счёт объёмов памяти последнего)!

И эти примеры — только пользовательская сторона приложений. Мы (как бы) не в курсе что у этих ребят на бекенде, что там с безопасностью, куда мы отправляем свои персональные данные и так далее, но у меня есть подозрение что там ситуация не лучше.

В целом, скрипты и сборка мусора — это отличные инструменты. Но это не повод их абузить, плодить тонну иммутабельной фигни чтобы тут же выкинуть, чтобы тут же нагенерировать новую тонну и тут же снова её выкинуть. А потом организовать пару зацикленных друг на друге островов объектов, и цеплять мусор уже к ним.

Время работы даже очень фигового программиста оказывается слишком дорогим даже для того чтобы сделать инструмент на худо-бедно надёжных технологиях? Или мода это теперь всё, а практичность — для нищебродных обиженок, которые слишком бедны чтобы каждый год обновлять свой парк техники?
Мегапост похоже что рассчитан на тех, кто способен по прихоти купить часы за 120к. Диванные наблюдения подсказывают что их около 10-20% от аудитории хабры, но не надо забывать что IT-сфера очень сильно защищена от экономических проблем, что с кодерами нянчатся лучшие кодероводы страны, тщательно ограждая от опасного нестабильного внешнего мира, чтобы кодеры ни о чём не волновались и спокойно себе кодили системы приносящие начальству много долларов. Но помимо кодеров есть ещё очень много разных людей, и к сожалению, они зачастую не могут нормально выбирать. Они берут максимально дешёвое по скидке, хотя в праздник можно и раскошелиться на пару тыщ. И те же диванные наблюдения подсказывают, что их гораздо, во много раз больше, чем кодеров, которые не думают откуда приходят и куда уходят денежки.

И у меня есть подозрение, что часть тезисов имеют за собой ложные исходные данные, потому что время и так было одним из самых важных факторов последние лет дцать.
> Вместо сотен метров за городом состоятельные люди предпочитают покупать компактные квартиры (35−50 м²) в центре.
Как раз потому, что загородные дома экономически невыгодны, и уходит слишком много времени (и средств) на поездку, не каждый готов жертвовать два-четыре часа в день исключительно на дорогу. А компактность обусловлена исключительно тем, что жилплощадь настолько дорогая, что даже у состоятельных людей нет возможности приобрести площади выше, чем указанные, не погружаясь в пожизненную кабалу. Были бы возможности — брали бы огромные дачные участки в центре городов. Туда же подписочные модели — они откровенно дешевле чем «покупка всех аудиотреков и фильмов, которые хотим прослушать», а в некоторых местах — единственная возможная модель (многочисленные аренды, мморпг с подпиской и другие услуги подписочной категории). В приведённых онлайн-играх с кастомизацией, кстати, время игры не требует оплаты, они без подписок. Это разные финансовые модели, хотя их и можно/нужно смешивать, принципиально они не зависят друг от друга. Всякие ютубы практически нахаляву (за просмотр рекламы) ищут похожий контент и дают его употребить.
Дорогие вещи, на сегодняшний день, далеко не всегда гарантируют что «они прослужат долго», последние много лет, чем дороже вещь тем меньшее время она прослужит после гарантийного срока, и куда выгоднее получается брать что-то средне-дешёвое и средне-сердитое, из средней ценовой категории: сломается — не страшно. И бездумные фанаты всего дорогого, на моём опыте, берут «хорошие вещи, чтобы на века», а потом сидят на гречке ещё пару лет после того как эта вещь окончательно и бесповоротно сломалась.
Ну и классический мультик про Аладдина вышел в 1994 году. Это было 26 лет назад. Тогда ещё не было никакой повальности подписочных систем (кроме аренды телефона и телевизионной радиоантенны) и кастомизации, концепция постоянного проживания в загородном доме и двухчасовых поездок на работу в центр была популярной и так далее, а Сторителлинг не был чем-то ретроградным.

Я вижу текст поста кучей надёрганных со всех сторон, из разных моделей и временных линий, удобных в данном контексте вещей, непонятно зачем, с непонятными выводами «сторителлинг, кастомизация и дорогие вещи — круто, а часы, которые отвечают всем этим критериям — ещё круче».
Не совсем, приходится регулярно подгонять размеры окошек, особенно если что-то случайно развернул. Два и более физических монитора всё таки выглядят эффективнее для разработки. Для кино с игрушками, разумеется, нет.
Собственно, основное назначение для подобного устройства — запуск софта, который работает под x86. Во-первых, это миниатюрные игровые консоли, запускающие ПКшные инди-игры, которые никто никогда не соберёт под ARM. Во-вторых — те же самые мелкие ПК, которые можно отсоединить от монитора на работе, положить в карман, притопать домой и подсоединить к домашнему дисплею, продолжив за ними работать.
В третьих, просто софт который на ARM работает значительно хуже (например, куча вычислений с плавающей запятой или требования особых процессорных инструкций, арм с этим справляется гораздо хуже).
> как тогда вы узнали, что человек шизоид
Я не имею достаточной квалификации чтобы диагносцировать, поэтому узнавал не я, узнавала моя сестра, имеющая высшее психологическое образование, после проведения определённого набора разнородных тестов (включая чаепитие с пациентом, хех). Я тут просто свечку держу. Как раз пытался общаться, там стабильно гнётся одна единственная генеральная линия вроде «Я тут самый крутой и замечательный, а все вокруг лошпеды, давайте танцуйте вокруг меня а я посмотрю» или «Я расчитал, что каждый человек за свою жизнь должен спариться ровно четыре раза в таком-то таком и таком возрасте, и вы тоже должны, срочно выполняйте мой план, иначе всем каюк. У меня тут ещё много теорий, и каждая отражает действительность гораздо лучше самой действительности.», и всё что выходит за пределы этого (включая критику, произвольной толщины и конструктивности) — игнорируется или вызывает резко негативную реакцию. Я, правда, видел довольно мало подобных образцов, но несколько штук наберётся.

> неужели Достоевский все еще пишет?
Разумеется пишет. Если мы возьмём точкой настоящего, например, 1869 год — Достоевский сейчас пишет Бесов :)
Для веб-формочек, гоняния json по http и пыха, зачастую достаточно восьми классов образования. Некоторые успешно занимаются этим даже с пятого.

Но не надо равнять всех программистов на веб-формовщиков. Программисты разные, и в среднем, им нужна довольно высокая (инженерная) квалификация в т.ч. с университетским матаном, теориями множеств и прочих графов. Даже самоучки занимаются изучением этого, просто потому что они хотят делать точные инструменты, и точно использовать существующие. Наш мир, к сожалению, зачастую довольно сильно ограничен, и у нас нет бесконечных мощностей для наивных решений уровня пятого класса.
Проблема в том, что нормальные программисты являются инженерами. Для программирования на чуть более глубоком уровне чем веб-формочки, обычно всё таки требуется некоторая инженерная квалификация и примерное понимание работы железки. И дипломы выдают с различными вариантами квалификации «программиста-инженера».
Берём выше. Запрет на руки, потому что ими можно кинуть камень.

Information

Rating
Does not participate
Registered
Activity