20.7
Karma
-1.9
Rating
khim @khim

User

Сколько стоят юнит тесты?

0
Всё это так, но если вы хотите получить какие-то осмысленные результаты, то нужны какие-то вменяемые исходные данные. Если вы рассматриваете вариант, когда у вас надёжность в компании с «бесконтрольным наймом сотрудников» и без написания юниттестов получается на уровне самых-самых лучших компаний, которые вкладывают в тестирование миллиарды… то тут вряд ли можно говорить о чём-то ином, чем подгонка исходных данных под ответ.

Сколько стоят юнит тесты?

0
Хорошая статья, показывающая что есть ложь, есть наглая ложь, а есть статистика.

Рассмотрим первый случай. Вероятность сбоя возьмем равной 33%, то есть инцидент, способный завалить их сайт надолго может произойти примерно раз в три года, что не так уж плохо.

Один инцидент раз в три года? Ну это примерно частота, с которой падают такие сервисы, как GMail или YouTube. Сервисы типа Steam или там Deutsche Bank — падают в разы чаще. И, разумеется, все эти компании вбухивают хорошие деньги в свои сервисы и в юниттестирование.

Сказать, что вы получаете вероятность сбоя за год 33% (без юниттестирование, напоминаю) — это примерно как рассмотреть вариант «мы наняли 500 водителей-такжиков по объявлению, ну а они, конечно, без тренировок и дополнительных затрат ездят чуть получше, чем Шумахер… ну… большинство из них».

То есть посыл статьи прост: если вы наняли супергениев, которые, по сравнению со средними программистами Гугла и Яндекса — как Эйнштейн по сравнению с трёхлетним ребёнком (работники Гугла — тут трёхлетним дети, это если вдруг, кто не понял)… то да, вам, видимо, юниттестирование не нужно.

Вот только… где вы берёте супергениев, которые без всяких тестов дают такую же надёжность, как у лучших компаний в мире со всякими многоуровневыми тестами, SRE и прочим… секретом не поделитесь?

Без такого «секретного места» ценность статьи, извините, близка у нулю.

Как id Software создавала Wolfenstein 3D на основе технологий из Commander Keen

+3
И именно поэтому ничего «великого и интересного» «каждый» произвести не сможет.

Чисто технически любая самая дурацкая поделка в Google Play сейчас превосходит по качеству Wolf 3D… Но поскольку технических проблем меньше (по большому счёту, по сравнению с тем, что было в описываемые в статье времена, их, можно считать, что нет вообще), то оказывается, что требуется что-то ещё… а тут уже выясняется, что это иные навыки и совсем, совсем другие затраты.

Это как с прибытием Поезда: сейчас подобную вещь сможет создать любой человек с несколькими приятелями и смартфоном… но это не будет «прорывом», как оно было сто с лишним лет назад… хорошо если пару сотен просмотров на YouTube получите…

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-2
Тогда встречный вопрос, что будет выводить следующий код и насколько интуитивно понятен результат с точки зрения новичка?

values = [['a!'], ['b!'], ['c!']]
print(map(lambda v : v.append('x!'), values))


А этот?

values = ['a!', 'b!', 'c!',]
print(map(lambda v : v is 'b!', values))
В обоих случаях будет выведено что-то типа <map object at 0x7fbcfd40eba8>, потому что вы генератор не превратили в печатный объект. Это, как раз, нормально новичками принимается. Или вы о чём-то другом? Тогда нельзя ли, всё-таки, сказать: чем именно вы недовольны. Тем что map возвращает не список, а генератор, тем что append возвращает None или тем, что is и == ведут себя по разному?

Из всего этого разнообразия меня удивило, когда я впервые столкнулся с python, разве что тот факт, что append ничего не возвращает — но в приличных тьюториолах на это особо обращается внимание… так что это может быть не самое логичное решение в языке, но если ворон на уроках не считать и не пробовать писать на python не читая доки вообще (как я лет 10 назад) — то неожиданностей быть не должно.

Ну почему же Вы так? Я ведь специально цитировал Ваши слова, причём мне кажется сложно забыть собственные слова, когда выделяете их полужирным текстом. Цитирую: «Все эти вещи очень-очень сильно выходят за рамки простой концепции Mapы, которая предполагает обработку множества элементов одинаковым образом». Объясняю: «по той ссылке есть код, который с этой точки зрения, технически, не отличается от моего примера». И нет, я не сказал, что тот код нарушает «концепцию map», я имел в виду, что он нарушает «Вашу концепцию».
От объяснения легче не стало. Может вы не туда ссылку дали? Я вижу там такой код:
        if isinstance(node, Tuple):
            return tuple(map(_convert, node.elts))
        elif isinstance(node, List):
            return list(map(_convert, node.elts))
...
Он использует Mapу в полном соответствии с её описанием в Wikipedia. Либо объясните где вы видите тут нарушение концепции, либо дайте ссылку на тот код, который что-то там нарушает.

Поэтому, хотел бы узнать, что же это означает?
Это обозначает что объекты обрабатываются Mapой независимо. И функция, которая их обрабатывает не знает контекста. То есть, соответственно, можно запускать такую функию на объектах в любой последовательности и, в частности, на разных машинах. См. MapReduce и всё прочее.

Почему функция не может обрабатывать элементы по-разному?
Потому что в этом случае разбиение большой Mapы на две маленькие или, наоборот, их слияние — дадут неверный результат.

Почему map не может передать несколько аргументов?
Именно потому что передача аргументов, не имеющих отношения к объектам бессмысленна (что вы туда передавать будете? постоянную тонкой структуры? зачем?), а передача информации об обрабатываемой последовательности — сделает Mapу — не Mapой.

Как можно доказать это уравнение в Python?
Это можно сделать только при определённых допущениях. Например вы можете сами положить ваш список в глобал и, соотвественно, оттуда функция обработки его достанет. Если же вы подобных «финтов ушами» не совершали, то у функции обработки просто нет информации, позволяющей одинаковые элементы, стоящие на разных местах обрабатывать по разному. И, поскольку у неё нет доступа к оригинальной последовательности — то её она испортить тоже не может.

Почему данное «фундаментальное свойство» нарушается в JavaScript?
Ровно из-за передачи пары дополнительных аргументов.

Только, трудно признать это удобным, если такое изменение появилось в «неправильном ЯП»?
Нетрудно. Я, собственно, даже не против подобной функции. Только не называйте её Mapой! Назовите, как в C++, transform или там foreach. Да как угодно назовите — только уберите ментальную связь с лямбда-исчислением.

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

А чо? Назовём угол в 60 градусов прямым, создадим «альтернативную геометрию». Удобно же. Нет таких. А почему нет, собственно?

Mapа просто определяется в лямбда-исчислении определённым образом — и дальше так и используется. И да, таких статей научных — достаточно. А вот таких, где была бы под Mapой понималось нечто странное, в духе JavaScript — я не видел.

Например, у нас есть обменные курсы из разных источников за пару лет и при применении map хотим чтобы функция имела возможность сравнивать каждый день с другими днями из всего списка и проводить определённые операции.
Если это действительно нужно, то нужно эту информацию передать в функция явно. Кроме того, если у вас действительно петабайты этих самых обменных курсов, то, возможно нужно обработку вести каким-то другим способом, а не передавая петабайт данных функции, обрабатывающей один элемент.

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

А что будет происходить с вашей Mapой если функция начнёт из контейнера объекты удалять?
Лично я считаю, что map не должен изменить обрабатываемый список.
Это замечательно если фунцию писали вы. А если нет? У нормальных людей всё гораздо проще: функция не может изменить объект, доступа к которому у неё нет. И всё. И не нужно читать её код, чтобы понять — разделяют вашу религию разработчики или нет… хотя в языке, где считается нормальным, что имена локальных переменных меняют поведения функций… это, наверное, считается необходимым…

Я лишь хотел намекнуть, что правильно выбирая свои инструменты, можно добиться очень хорошими результатами не тратя время и деньги впустую.
Я вот в этот не уверен. Потому что практически я наблюдаю буквально человеко-годы, которые выбрасываются на подобные «хорошие результаты».

То есть я принимаю ситуация, когда кто-то, специалист не в программировании, а, не знаю, в торговле на бирже или в проектировании холодильников, творит что-то вот этакое на JavaScript… просто потому что в Python или Haskell он не умеет — ну а потом, понятно, специалистам это расхлёбывать. Это — нормально.

Но мы-то вроде, говорим о другом, о том, что вы, как специалист, что-то такое хотите создать. Неважно даже — имея прототип на .BAT-файлах или Pascal, неважно.

Тут-то откуда PHP может возникнуть?

Как Вы можете написать такое, не зная, что это за приложение и какие данные оно обрабатывает?
Очень просто: я просто тупо приплюсовываю к цене вашего хостинга цену за пару часов моей работы.

Или что «гиг памяти и 25GB на SSD» обязательно сделает любое приложение быстрее?
Нет, этот сервер просто позволит мне не пытаться пользоваться опасными инструментами. И если это даст экономию в пару часов моего рабочего времени в год — то он себя окупит.

Вы ведь понимаете, что если на слабой машине технология X была в десять раз быстрее чем Z, то на более мощной машине это соотношение практически не меняется?
Извините — но это неправда. Всё зависит от того, что именно ваше приложение хранит в памяти между запросами.

Но даже и это неважно: важно не только то, какой скорости вам позволит та или иная технология (если бы это было так, то мы бы писали всё до сих пор на ассемблере), а в какую цену вам обойдётся разработка плюс хостинг. И если вам потребуется заплатить чуть больше за более дорогой хостинг, но при этом вы сделаете систему быстрее и ошибок там будет меньше — то это вполне неплохой компромисс. PHP недаром на 7м месте сейчас и уверенно движется к вылету из десятки — а когда-то, было время, в тройку входил…

Чтобы не было вопросов, почему иногда я выбираю ту или иную технологию, напомню, что делаю это неспроста, а потому что, например, ab и siege подсказывают, какая технология будет обработать больше всего запросов.
Больше всего запросов вам позволит обработать модуль на C++ для NGINX. Но это не значит, что я для каждого сайта буду его писать. Хотя, в зависимости от задачи, вполне умею и его изобразить.

Ну, а для тех, кто не любит проводить тесты самостоятельно, рекомендую: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php.html
Что этой ссылкой вы пытаетесь доказать? Что оба языка имеют скорость между «жутко медленно» и «о… ть как медленно»? Если вы уж так любите эту пузомерку — то взгляните уж сюда.

Если у меня будет стоять задача сделать что-то быстрое и затраты на VPS будут меня реально напрягать — я не буду делать это ни на JavaScript, ни на PHP, ни на Python. Ибо в этих случаях выбор — из двух вариантов: C++ или, возможно, Java. В последнее время к этому списку ещё Rust добавился (но на нём разработчиков пока не так много), или, если у вас есть разработчики под Windows — можно C# взять (но у него проблемы с кросс-платформенностью).

Если же я вообще рассматриваю как вариант PHP, Python или JavaScript — то это значит, что скорость работы для меня не критична. И в этом случае ссылаться на скорость работы PHP не очень интересно.

Трагедия Common Lisp: почему популярные языки раздуваются в сложности

0
+ А, разве существование JVM не подстёгивает производителей процессоров и «компиляторов» ускорять и этот код так или иначе подписывая всякие NDA взаимно?
Не работает. Jezelle и прочие подобные архитектуры — не работают. Потому что если у вас есть один байткод (неважно x86 или ARM) — то зачем вам ещё один? Вы всегда можете спуститься и реализовать критический участок кода на «нативной» ISA, вызвав его через JNI.

Все основные реализации CLI и JNI — сейчас открыты. Возможно у Ларри хватит ума попробовать закрыть JVM… ну так он только загонит свою версию JVM в нишу, откуда ей уже не выскочить.

Трагедия Common Lisp: почему популярные языки раздуваются в сложности

0
Ну нет, в первую очередь это проблема некоторых производителей процессоров.
Ну да, конечно. Если учесть, что речь идёт от AMD, ARM, Intel, IBM и Oracle… кто там у нас остался-то? Zylog?

Ну нет, uops и байткод — не одно и то же.
Конечно нет. Откуда вообще такие идеи? Современный байткод — это x86 ISA и ARM ISA. Я думал уж это-то очевидно.

Во-первых микрооперации вряд ли когда-то будут общими для всех производителей. Во-вторых они слишком убоги, чтобы называться байткодом
x86 — вполне себе полноценный байткод. И его поддерживают как в железе, так и в софте (тот же E2k). Только, как и следовало ожидать, поскольку он изначально под такую роль не затачивался — эту функцию он исполняет плохо.

Во-первых я бы поостерегся утверждать, что ничего нового в означенных архитектурах не появляется
Я не сказал что там ничего нового. Я сказал ISA, байткод, «застыл». А внутри, где-то в недрах, скрытых от глаз, да, там движуха, разные интересные ирхитектуры. nVidia, МЦСТ — всё это вот… только оно, в силу того, что на нормальный байткод так и не перешли — делается с суррогатом байткода…

благодаря тому, что байткод не стал обязательным условием существования процессора.
Благодяря? Я бы сказал «вопреки». «Благодаря» тому, что мы нормального, общего для достаточно большого процента программ, байткода так и не получили — все разработки ведутся «за закрытыми дверьми», в частных компаниях. Средние века в чистом виде: накрылась Transmeta — все нароботки пропали, если, вдруг, накроется Huawei — эти тоже сгинут.

А, и еще — вы конечно не стали упоминать про Nios, Microblaze, Эльбрус, миллион различных DSP-архитектур, поскольку все они, дескать, не так распространены. Но они есть — а их бы не было, ага.
А они просто тут вообще никаким боком. Если на процессорах не запускаются «ширпотребные» программы — им от байткода, C# и прочего — ни горячо, ни холодно.

Байткод, кстати, выстрелил, хотя и ограниченно: если бы не Java, то скорее всего у нас, для этих программ, были бы не две (x86 и ARM), а одна (x86) архитектура…

Трагедия Common Lisp: почему популярные языки раздуваются в сложности

0
И что значит «это не его беда»? А чья в конечном итоге?
Нас всех, в некотором смысле. Вот весь этот бесконечный сериал со Spectre и его бесчисленными родственниками — он, в общем-то, от невозможности отказаться от поддержки старых C/C++ программ. Оттуда же — проблемы с многопоточностью и многим другим.

С другой стороны если все придут к одному байткоду, то в конечном итоге появятся исполняющие прямо его процессоры (а-ля Jazelle, а потом и глубже) и в конечном итоге только они и останутся.
А это уже и так произошло, в некотором смысле. Современный x86 процессор и многие ARMы исполняют код, имеющий мало отношения к x86 или ARM ISA. Он транслируется «на лету». Вот только поскольку этот, с позволения сказать, «байткод» слабо приспособлен к безопасности (ну не для этого его делали) — то имеем то, что имеем.

а кроме того не будет стимулировать развитие новых архитектур.
Дык их и так нет. Что у нас сейчас из нового? x86 родом из 1978го да ARM из 1983го? Ну да — ещё AVR из 1996го. Свежачок-с.

«Внутри» — да, там идёт масса разных исследований. А вот «снаружи», как раз — архитектора особо не меняется. Просто вместо байткода, который ну хоть как-то был спроектирован с какой-то там расширяемостью и продуманностью — имтируется архитектура «давно ушедших дней».

Анализ сишного Hello World

0
Ну дык эта ж проблема не на ровном месте появилась. Просто переход через границу привилегий — это реально сложная задача. Нужно много чего сделать при переходе «туда» и «обратно».

И попытки ускорить не провалились. От тысяч тактов мы перешли примерно до 300-400 тактов. А последующие улучшиния довели это время до сотни примерно.

Проблема в другом. На каком-нибудь 80286 — «поход в ядро» тоже под сотню тактов занимает… но там и вызов функции — тактов 20-30. А у современного процессора это получается сделать за 5-6.

То есть проблема не в том, что кто-то замедлил «поход в ядро». Проблема в том, что «обычные» операции стали сильно быстрее работаеть.

P.S. Кстати очень хорошо видно почему те же люди, которые устроили все эти индирекции в GLibC грязно ругают тех, кто поверх этого десять слоёв абстракции навесил — они абсолютно правы. Потому что «навесить» 3-4 «быстрых» вызова по 5-10 тактов и за счёт этого получить вдвое меньше системых вызовов — это таки очень-таки неплохая экономия. Один системный вызов как 20, а то и 30 вызовов функций стоит. А вот если вы добавляете к цепочке функций ещё один слой и не получаете уменьшения количество вызовов в каком-то месте… то это в чистом виде замедление.

Трагедия Common Lisp: почему популярные языки раздуваются в сложности

0
И, повторюсь, отказ от ДОС-программ совсем не то же самое, что отказ от Win32-программ.
А в чём разница? В том, что Project Avalon так и не взлетел? Ну кто ж тогда, когда его затевали, про это знал.

Процитированный вами комментарий был призван обратить ваше внимание на то, что светлые воспоминания Билла про опыт работы на мейнфреймах вряд ли мог настолько затуманить его мозги, что он и в 2000-е рассуждал в тех же категориях.
Почему «затуманить»? Скорее прояснить. Развитие персоналок шло, вообще, впараллель с развитием мейнфреймов — только со сдвигом на 15-20 лет. IBM/370 (1970й) — «плоское» адресное пространство и вирутализация… аналог — 386й в 1985м, векторные регистры в 1976м… повторёны 1997м и так далее. Исходя из этого 15-20 летнего сдвига и того факта, что AS/400 начала заменять IBM/36 в начале 80х (и закончила ближе к 2000м) рубеж тысячелетий как раз попадал на момент, когда программы должны были перестать писаться в машинных кодах, а где-то к 2010му, как раз, переход должен был быть завершён — что Microsoft, собственно, и попытался реализовать…

Не его беда, что персоналки вот в этом месте отказались следовать в фарватере «больших» машин…

Раньше появления такого интерфейса пульты не пропадут.
Когда-то подобные вещи говорились про фотоаппараты и даже будильники…

Они, конечно, не то, чтобы пропали — просто денег там нет, как и новых разработок…

P.S. Интересно, кстати, что программы, в итоге, сейчас зачастую в машинные коды не компилируются — однако и единой системы кодирования, как в AS/400, не появилось. Java, JavaScript, C#, Python… кто в лес, кто по дрова. Осталось понять только — хорошо это или плохо… Если честно — даже не знаю.

Как делать сайты в 2019 году

0
Это тренировка сообразительности. То же самое в играх мобильных, которые настойчиво отправляют тебя сделать review.

Нужно согласиться и отказаться — так как отправить туда они могут, а проконтролировать чего ты там понаписал — нет. Хотя некоторые разработчики прикрутили уже «второй внешний контур»: review выгружаются с маркета через консоль разработчика и тебя перестают задалбывать только тогда, когда review реально появляется…

Как делать сайты в 2019 году

+3
У меня на мелком ноуте Хабр занимает 60% экрана по ширине. В результате я либо наблюдаю кучу неиспользованного пустого места, либо обрезанные сообщения.

И не надо мне рассказывать сказок про то, что если текст сделать чуть уже — то небо упадёт на землю и случится вселенская катастрофа.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-1
А на деле — копнешь чуть глубже и вы начинаете путаться в терминах и уходить от темы.
В теме написания говнопрограмм я действительно не разбираюсь. Да и не хочу разбираться.

Вообще показательно, что там где я перепутал термины и написал вместо «отношение порядка» «операции порядка» — вы пошли гуглить, а не указали на путаницу.

Это одна из фундаментальных вещий — но, конечно, знатоках JavaScript она ни к чему.

А четыре арифметических действия не хотите поправить или улучшить? А то там, может, тоже математики налажали.

Или их вы тоже сейчас гуглить пойдёте?

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-1
Ну и при чем тут не иммутабельный список? Он и без дополнительных аргументов в .map такой.
И ровно поэтому mmap в JavaScript — не Mapа.

У математической функции Map есть в сущности ровно одно несколько фундаментальных свойство: (map f)⚬(map g) = map (f ⚬g). Оно не выполняется в JavaScript ровно потому, что Mapа там — нет Mapа.

Причём этому мешают оба «улучшения», которые имеются в JavaScript: мы можем как изменить объект для которого вызвана Map, но, кроме того, во время обработки — мы обязаны передавать туда объект — который там, в функции, может поменяться.

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

P.S. Обратите, кстати, внимание, не мой пример с push и подумайте — сколько «стоит» поддержание всего этого. В том-то и дело, что «улучшенный» интерфейс, принятый в JavaScript — он далеко не бесплатен. Это если даже забыть про «проблемы идиотов-математиков» (а как бы классно без них было… никаких проблем с Mapой, JavaScriptом и компьютерами… в силу отсутствия и первого и второго и третьего)

13 самых заминусованных статей минувшего года

+2
r/o — это вообщ не «процесс».

В r/o отправляет администрация если кто-то посылает ссылку на что-то, достойное r/o (комментарий обычно).

С учётом того, что статья в плюсах, а аккаунт r/o — скорее всего что-то там было в комментариях, а не в статье…

Трагедия Common Lisp: почему популярные языки раздуваются в сложности

0
Вы вообще — в курсе, что в Windows x64 программы для DOS и Win16 не работают? Или сейчас будете рассказывать сказки о том, что только что об этом узнали?
В курсе. Но что это доказывает, я не понял?
Что один раз отказ от старых технологий сработал — почему бы ему не сработать ещё раз?

Когда ДОС-программы работают в эмуляторе, то от них никто ничего особенного не ждет (работают они между тем неплохо). А вот от «тяжелых» и неоднозначно спроектированных Win32-программ вряд ли бы кто-то ждал работы «как в эмуляторе».
Ну в 97м или 98м и от DOS программ никто не ожидал от «тяжёлых» программ, что они будут «как в эмуляторе» работать. Собственно Windows 1.x и 2.x мало кто пользовался именно потому, что там старые программы плохо работали.

Такой же план был и тут: создать новый «managed» мир, перевести всех пользователей туда — а уже лет через 5-10, когда других программ не будет писаться… сказать что «всё — теперь Win32 программы будут работать только в эмуляторе».

Не сложилось… но идея была именно в этом. Кстати отказались от неё весьма поздно: Windows 8 была последней попыткой эту идеё продавить-таки. Но массовое неприятие пресловутого интерфейса наконец-то положило крест этой затее.

И да, пожалуйста, на надо мне тут же примеров подключения подсветки аквариума к малинке, я говорю просто о пульте, простом китайском пульте из магазина.
Можно примерно прикинуть когда простой китайский пульт из магазина обзаведётся Linux'ом.

Угу, а я вот в детстве думал, что телефоны бывают только проводными. А вот дожил до чего… Времена и люди меняются, не находите?
Ну если вы застали времена до DECT (это 80е), то могли бы и вспомнить, что в те времена мейнфреймы (на которых, вообще-то многозадачная OS ходила) обладали меньшими ресурсами, чем этот самый китайский пульт сегодня.

Просто требования Linux несколько выросли с момента его появляния… но вот не могу сказать почему вы решили, что его в этом пульте не будет (хотя мне кажется, что более вероятно, что не станет самого пульта: подсчетка аквариума просто будет частью пресловутого «умного дома» и отдельный пульт будет просто не нужен).

Тут вы правы конечно, хотя без «галочки» дело тоже не обойдется. Иначе грош цена такому «безопасному» программированию.
Да, конечно, но, как известно, галочек сейчас и у Linux и Windows достаточно… а безопасности нету…

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-1
Спустя восемь лет нас удивляют всё те же вещи )
Дерьмо остаётся дерьмом и через восемь лет и через восемьдесят.

P.S. Ответ на вопрос с bind становится резко понятен при замене '33' на '333', например…

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-1
Что не делает JS'овский .map «менее математичным»
Это делает JS'овский map не имеющим никакого отношения к математике. Всё равно как если бы у вас символом "+" обозначалась операция деления, а сложения в языке вообще не было бы.

Вы бы были готовы работать на таком языке? Я — нет. Вот и с JavaScript такая же история: в тех местах, где его «обойти» нельзя, я, конечно, с ним общаюсь. Но стараюсь делать как можно больше на других, более вменяемых, языках.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

0
Поменяйте местами типы в вашем выражении и python2 вам так же радостно скажет что оно — True.
(12 < «13») and (13 < «5») and (5 < «12»)
И именно потому что это — дерьмо собачье в Python3 это исправили. Если бы они, при этом, ещё и работу со строками не поломали… Впрочем в Python 3.7-3.8 всё уже более-менее удобоваримо…

ПС большинство языков со строгой типизацией вам вообще не даст сравнить строку с числом.
Конечно — это их главное преимущество.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-3
Для меня выглядит «немного неправильно» получить все записи сортированные в определённом порядке, применить HTML разметку для каждой записи, а потом выкинуть часть элементов.
А почему, собственно? Вы когда-нибудь Excel'ем или Google Docs пользовались? Там фильтры есть. Можно выкинуть все строчки со словом «красный» или с числами больше 100 или ещё какие-нибудь. И таблички с кнопочками которые реагируют на эти действия. Вы что — считаете, что это нормально, когда на каждый чих табличка формируется с нуля?

Во-вторых, как уже сказал, я считаю, что плохой код рождается по вине разработчика и если разработчик сначала будет сделать всю тяжёлую работу, а потом выкинуть часть обработанных элементов — ни один язык его не спасёт.
Плохой код рождается от непонимания того, что и где у вас происходит в программе, в первую очередь. А для такого понимания — нужно, чтобы программа состояла из простых компонент. «Обработать 100 элементов по одному и вернуть их» — это простая концепция. Mapа в JavaScript — сложная. Ну вот просто сложная. Вот вы можете сказать что сделает вот такой простой код:
[1, 2, 3].map((x, i, a) => a.push(i))
Ну там, по наитию, не читаю мануалы до посинения? А почему?

Я где-то читал классную фразу «Good language have to be not just easy to use, but it should be hard to abuse». При этом вторая часть — на самом деле важнее первой.

Получается, даже разработчики Python нарушают эту концепцию? Например, беглый поиск находит это (уверен, это не единственный случай).
Я не знаю что именно вы искали и почему то, что вы нашли нарушает концепцию Mapы, извините.

Лично я не видел какие-либо ограничения, на что должна возвращать функция, также как и какие аргументы, она должна получать.
А очень просто — в той же википедии, если бы прочитали статью до конца, вы бы увидели там фундаментальное свойство Mapы:
(map f)⚬(map g) = map (f ⚬g).

Это такое же фундаментальное свойство Mapы, как коммутативность у сложения или умножения. Это, собственно, то, что делает Mapу Mapой и над которой потом строятся другие вещи (типа MapReduce).

В JavaScript Mapа — она, я извиняюсь, не Mapа. Так зачем использовать неподобающее имя?

И разве, это не те «самые лошади», когда другие не могут усовершенствовать функцию из-за боязни/нежелании сломать «старые концепции»?
Отчасти да. Накидайте-ка ссылок на научные журналы с обсуждением функций высшего порядка, совместимых с примером выше? Нету? А почему нету?

А я отвечу почему: потому что нельзя создать теорию «кучи мусора».

Ну разумеется нет. Если вы передаёте в function этот самый object — то вы должны гарантировать, во-первых, что этот object во-первых существует
Если честно, не понял, что Вы имеете в виду, и как передача дополнительных аргументов влияет на это.
Очень просто. Возьмите тот же самый MapReduce. Когда мы обрабатываем петабайты данных. Что мы должны передать в Mapу в качестве третьего аргумента и зачем? Или вот такой код
def HelloReader():
   with open('hello.txt') as hello:
     for line in hello:
       yield line

map(lambda(x) : "| " + x, HelloReader())
Тут, вы, конечно, можете передать в Mapу генератор — но какой в этом смысл и что вы там с ним будете делать? А что будет происходить с вашей Mapой если функция начнёт из контейнера объекты удалять?

Например, если на php-fpm+nginx я смогу создать некое веб-приложение, которое будет работать на VPS за $2.99, обработать сотни тысячи запросов в день и держать load average ниже 0.1, при этом мне не придётся кувыркаться из-за простых вещей вроде strip_tags, то я не перестану использовать PHP только из-за идеологических соображений.
А зачем мне может потребоваться такое приложение? Если это мой проект — то я, уж как-нибудь найду $5, чтобы не вмазываться в это гуано, а если это на заказ, то я просто не буду с ним связываться. Потому что если у закачика нету $50-60 в год на оплату хостинга, то откуда у него возьмутся какие-то деньги, чтобы заплатить за работу мне?

Времена, когда форум на PHP можно было захостить за $15-20 в месяц, а личная VDS с гигабайтом памяти начиналась от $200-$500 — в далёком-далёком прошлом. Сегодня за $5 в месяц можно получить гиг памяти и 25GB на SSD — чего хватает даже для каких-нибудь Enterprise Java решений под небольшую нагрузку. Зачем, в этих условиях, связываться с PHP — я представить себе не могу.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-1
А что вам мешает ездить на JavaScript-велосипеде по дороге? Отсутствие колёс сейчас не учитываем.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-2
Вместо той mapы, что в JavaScript уж точно лучше написать for — хотя бы иллюзий не будет.

13 самых заминусованных статей минувшего года

+1
А достигать как планируется? Путём уменьшения количества квот или как в известной загадке, когда одна бусинка из вазы вынимается, две новых кладутся — а в полночь, оп-па: ваза пуста.

Я вас разочарую: в реальном мире — это не работает.

13 самых заминусованных статей минувшего года

0
чем больше видится женщин в индустрии, тем меньше давление среды, тем более «нормальным» это становится в обществе.
Я думаю мы это увидим довольно скоро. Примерно лет через 5 — когда вот те самые женщины, прошедшие те самые курсы, выйдут из ВУЗов.

Если ваши идеи верны — то «курсы питона для женщин» должны после этого отмереть и наступит нирванна (ну как же: среда нормализуется, дискриминации больше нет).

Если мои — то возникнут «квоты для женщин», за нарушение которых компании будут штрафовать и прочее (поскольку женщины по прежнему «не подходят», а их ведь навыпускали — девать их куда-то надо).

P.S. В принципе этот идиотизм уже наблюдается, хоть не в IT… но посмотрим чем завлекуха с курсами питона кончится…

Старикам здесь не место? Программируем после тридцати пяти

13 самых заминусованных статей минувшего года

+2
Потому что ваша статья — это хорошее исследование. Вы не поленились разобраться в истории, посмотрели на разные смежные вещи — и не стали делать, даже из вашей обширной статьи, делать далеко идущих выводов (может потому и не стали, что из неё видно, что всё далеко не так однозначно). А ваш оппонент — всё сделал наоборот.

Ну так удивительно ли, что реакция тоже была противоположной?

13 самых заминусованных статей минувшего года

-1
Я надеюсь вы не про физический орган?
А про какой ещё? Столь радикальное решение (создание отдельной изолированной среды), разумеется, требует столь же радикальных посылок.

Среда им мешает
А почему тогда среда вдруг не мешает «настоящим белым людям», когда они встречаются с «чернозадыми макаками»? Почему, вдруг, тут — мы это не считаем проблемой, а в случае с женщинами — считаем?

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

Почему на Кубе (где никаких спецпрограмм «выравнивания» в ВУЗах нету) врачей-негров (причём хороших врачей, США лишь недавно обогнали Кубу по средней продолжительности жизнь при совершенно несравнимых затратах на медицину) — куда больше, чем в США?

Потому что там нет сегрегации по рассовому принципу в школах.

А почему её там нет? А потому что там нет дилеммы одного моего знакомого, живущего в США, которую он сформулировал очень красиво: «мой ребёнок может быть в классе либо самым бедным, либо самым белым».

То же самое и с этими идиотскими курсами Питона: мы вначале создаём общество, где женщины не могут пойти на курсы программистов не оказавшись заклеймёнными сверстницами — а потом начинаем решать эту проблему создавая какие-то странные курсы.

Ну не работает это. Либо «дозу» придёся повышать (требуя квот для женщин уже в ВУЗах и фирмах), либо будет откат.

Если вы хотите решить проблемы — нужно решать её там, где она возникает…

13 самых заминусованных статей минувшего года

+1
Есть смысл помогать тем, кто в более проигрышной позиции, чем тем у кого есть фора. Это не дискриминация, это сфокусированная помощь.
Совершенно верно. А теперь ответьте на вопрос: какой именно орган мешает женщинам программировать на Python? Почему, вдруг вы решили, что они оказались «в более проигрышной позиции»?

Хотите им помочь — открывайте себе курсы для белых мужчин, никто не мешает же.
Пробовали уже. Даже не курсы открывать, а просто шутки брать от представителей меньшинств и заменять там black на white и наоборот.

Огребли так, что до курсов не дошли.

13 самых заминусованных статей минувшего года

0
Таак. А теперь — как там с гендерным равенством среди архитекторов… Ах ну да, конечно же: неравенство женщин и мужчин в архитектурной среде, похоже, не вызывает сомнений.

По моему вы тут только подтвердили тезис @ Neikist, @ DrPass — архитектура тоже имеет ровно те же проблемы.

Просто она не такая хайповая и вокруг отсуствия девушек-архитекторов не бьётся столько копий…

13 самых заминусованных статей минувшего года

-2
Никакая генетика не мешает спокойно пилить фронтенд по темплейтам.
С этим я совершенно согласен, но есть одна проблема: «пиление фронтенда по темплейтам» — это временная развлекуха, которой компании занимаются, пока у них есть на это лишние деньги.

Если завтра они пропадут — то вся эта бурная (и по большей части бессмысленныя) деятельность исчезнет и окажется, что большинству компаний никакой фронтенд в принципе не нужен, а достаточно странички на VK или Facebook'е.

И что тогда делать с армией людей, которые только на это и способны? Особенно когда выяснится (а это обязательно выяснится), что успешные компании «почему-то» имеют меньше девушек в штате, чем «положено»?

В тестировании, например, женщинам вообще конкурентов нет, внимание к деталям потрясающее.
Однако платят там меньше, что породит ещё один виток попыток искоренить несуществующую дискриминацию.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-2
то что это работает не так как в языке, на котором вы писали раньше
Проблема в том, что это не работает как в математике, откуда все эти понятия взяты. То есть весь математический аппарат, вокруг этого наработанный, можно забыть.

Так зачем смущать людей, используя названия, которые влекут за собой вполне определённых ожидания — если вы, потом, эти ожидания нарушаете?

Можно использовать нормальные ide<ёblockquote>А можно использовать нормальные языки, которые не требуют, как идиоту, тыкать в каждую букву на экране, чтобы понять что она значит.

И кстати, вы не показали, что ваша IDE покажет на Map'у — что, как раз, гораздо интереснее и важнее.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-1
Чем Array.map в js не соответствует этому описанию?
Хотя бы тем, что вы не можете гарантировать, что вызов функции для одного элемента будет зависеть только от этого элемента. Всё из той же статьи:

Математическая основа операции map позволяет проводить множество оптимизаций.
(map f · map g) xs (где «·» — оператор композиции функций) эквивалентно map (f · g)
то есть (map f)⚬(map g) = map (f ⚬g). Эта оптимизация избавляет от необходимости в двукратном вызове map за счёт совмещения применения функций f и g.
Так вот, сюрприз-сюрприз, для Javascript — эта оптимизация невозможна. Именно из-за того, что map тут — это не map, а чёрт знает что.

И конечно то самое место, куда будешь пихать любую функцию, независимо от ее аргументов…
Ну, как бы, ты ожидаешь, что аргумент-то будет один, да.

Но как я уже сказал, главная проблема Mapы в JavaScript — это не проблема на КДПВ (это впросто завлекуха), а в том, что Mapа в JavaScript — это не Mapа, == — это не операция сравнения, < и > — это не операции порядка и так далее. Подвох на каждом шагу. Хуже, чем в C.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

0
Возможно, это не очень правильная позиция, но лично я не пытаюсь искать слабые места каждого языка.
Как можно осмысленно выбирать языки если не знать и сильных и слабых сторон?

Вы никогда не задумывались почему JavaScript и PHP — это «ужас летящий на крыльях ночи», почему C — это коллекция граблей, за которые вас всё время стремится наказать компилятор и так далее?

Это ведь не случайность. JavaScript и PHP — изначально постулировали задачу «сделать так, чтобы разработчик без опыта мог создать скрипт — он бы начал работать с как можно меньшими усилиями». Какое для этого было выбрано средство? Язык старается «додумывать за программиста — и не всегда успешно. Когда я пишу „333“/3 — я, вообще, чего получить-то хочу? 2222 (111 делённое 3) или „3“ (треть от исходной строки)? Идеи о том, какой тут будет ответ у разных людей могут сильно разниться.

Эта же Mapа с дополнительным аргументом в сочетании с функциями, которые имеют неочевидные дополнительные аргументы… это же всё — из попытки „помочь“.

Только в больших проектах эта „помощь“ боком выходит.

Ну а C — это, напротив, попытка „развязать руки компилятору“ за счёт ограничения программиста. Что, в результате, приводит язык к „близости к железу“ (ибо компилятору не нужно лишних проверок в код вставлять, чтобы a << 257 правильно обработать), а это, в свою очередь — к попыткам использовать C как „переносимый ассемблер“.

Ну и так далее.

А вот эта проблема с else — это уже чистой воды случайность. Можно понять почему так получилось, но глубокой идеи за этим не стоит… особенно в Pascal, где, скажем, record всегда имеет свой end… а вот if — не имеет. Просто недодумали вовремя.

Извините, но не заметил такой вопрос. Например, в JavaScript имеем возможность написать this.getAll().map(this.markupRows) а метод markupRows сможет:
— сравнивать текущий элемент с предыдущем/следующим элементом
— узнать еслу текущий элемент это последний/первый элемент
— обработать первые n элементов особым образом
— добавить классы для стилизации таблицы-зебры
Хорошие примеры. Хотя вопросы безопасности тут сразу встают в полный рост. Потому что представьте себе, что вы добавили „классы для стилизации таблицы“ — а потом, в рекламируемом тут .chained подходе выкинули часть элемнтов? И что будет с вашими „первыми n элементами“, если их число, дальшейними фильтрами, изменится?

Все эти вещи очень-очень сильно выходят за рамки простой концепции Mapы, которая предполагает обработку множества элементов одинаковым образом. И может, в некоторых языках, даже автоматом раскидать эту обработку по разным ядрам процессора — в JavaScript это в принципе невозможно… именно из-за выбранного интерфейса.

Возможно я ошибаюсь, но думаю что оптимальнее всё-таки использовать map(function, object), при этом map должен передать функции все необходимые аргументы, а уже в function будем решать, что делать с ними (в том числе, игнорировать ненужные аргументы).
Ну разумеется нет. Если вы передаёте в function этот самый object — то вы должны гарантировать, во-первых, что этот object во-первых существует, а во-вторых никто к нему, кроме этой функции Map доступа не имеет. Это сериализует всё операцию и очень сильно связывает руки реализации. Dart, кстати, во многом отсюда: разработчики V8 обнаружили, что достигли „потолка“, когда вот эменно подобные „эффективные“ решения не позволяют сделать UI быстрее… и решили всех пересадить на новый язык.

Никакого успеха, понятно, не достигли — но это уже другая история.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

-2
А вам серьёзно ради этого нужно Map'у портить?
render () {
 var index = 0;
 return items.map((el) => `<li element={el} tabindex={index} />`)
}
Это прям так ужасно? Катастрофа? Много вы таким способом строк наэкономили? А если много — то почему web-странички занимают мегабайты?

Горький урок отрасли ИИ

Трагедия Common Lisp: почему популярные языки раздуваются в сложности

0
Условная софтина под ДОС, не работающая с железом (либо если железо можно было как-то эмулировать) могла потом работать и в винде.
А вы пробовали? Огромное количество софта под DOS в Windows NT (всех версий) либо не работают вообще, либо работают очень плохо. Win16 программы — работают неплохо, да.

Потому и потребовался промежуточный переход через Windows 9X… а уже в XXI веке — поддержку DOS выпилили окончательно… как и Win16, кстати…

Условная софтина под Вин32, запущенная в ОС типа «Сингулярности» внезапно не запустилась бы «как есть», а в эмуляторе она работала бы… как в эмуляторе.
Ну то есть так, как работают DOS-программы в Windows сегодня.

Вот и вся разница между этими «очень похожими» примерами.
Ну то есть никакой принципиальной разницы таки нету?

Вы вообще — в курсе, что в Windows x64 программы для DOS и Win16 не работают? Или сейчас будете рассказывать сказки о том, что только что об этом узнали?

Кто из Майкрософта в начале 2000-х мог рассуждать категориями «а вот в System 370 было иначе, вот это была настоящая система»?
Билл Гейтс, хотя бы. Он-то с мэйнфреймов начинал. И Бейсик свой присал на эмуляторе, если вы не в курсе.

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

Разумеется в таком мире заботится о надёжности и безопасности — по меньшей мере странно. А то что Singularity «не взлетела» — это так, мелкий «side effect».

Сами себе противоречите — она полностью соответствует стандарту, или все же имеет заточки под шланг и гцц?
Он полностью соотвествуюет стандарту, но в нем есть некоторые места, которые нужны, что GCC не ругался.

Как пример:
template<typename T, typename U,
         bool NeedToTranspose =
            (int(T::RowsAtCompileTime) == 1 && 
// FIXME | instead of || to please GCC 4.4.0
// stupid warning "suggest parentheses around &&".
// revert to || as soon as not needed anymore.
              int(U::ColsAtCompileTime) == 1) |
             (int(T::ColsAtCompileTime) == 1 &&
              int(U::RowsAtCompileTime) == 1)
>
...
Как несложно заметить — выражение и с || и с | будет делать одно и то же. Однако GCC на «более естественную» версию ругается — потому ради него сделали некоторую странность… а для armcc такого никто делать не будет.

И попробуй это нытье оспорить.
Легко. Операционки, основанные на этом «комьюнити», стоящие на миллардах устройств и поддерживающие миллионы приложений — известны. Подобных же на Keil — не наблюдается.

Не вполне понятно, почему вдруг там должно сформироваться общее поле или общая платформа с ПК
А почему нет? Софт для мобил — тоже когда-то был «своей особой поляной». Всякие Java ME и прочее. Ну и где оно это всё?

Использовать общую среду — просто удобнее. Вопрос только в том — окажется ли ваша платформа достаточно мощной, чтобы использовать соответствующие инструменты или нет.

Когда-то и C казался в эмбеде экзотикой и считалось, что ассемблер — это «наше всё».

Почему вы считаете что на C всё остановится?

пока вы ВСЕ не перепишете, у вас и не будет этого программирования.
Однако у вас будет меньше ошибок, меньше утечек данных и меньше крешей. В этом ведь цель, а не в том, чтобы галочку где-то в отчёте поставить.

Так не все ли равно, в каком порядке это делать?
Нет, не всё равно. Очень сильно не всё равно.

Пример мы тут разбирали вот буквально несколькими абзацами выше: современные версии Windows ни программы под DOS, ни программы под Windows 3.1 не поддерживают (иначе как в эмуляторе) — и люди отлично ими пользуются. А что было бы, если бы вместо Windows 95 вышла Windows NT, которая поддерживала бы только Win32?

Я думаю сегодня мы пользовались бы какой-нибудь другой OS…

UPD: By the way, кто и зачем вас так стабильно минусует в этом топике?
Я-то откуда знаю?

Анализ сишного Hello World

0
Не по сравнению «даже с походом в ядро». Поход в ядро — это не дорого. Это очень дорого. Сотни тактов. За которые суперскаляр может исполнить тысячи операций.

На этом микроядра погорели. Современная архитектура, вообще очень плохо «ложится» на современные стили написания программ. Что довольно грустно.

Так-то хорошо было бы жить в мире где то, что считается «хорошим стилем» было бы не только «красиво», но и «эффективно»… Но уж где живём — там и живём…

Анализ сишного Hello World

+1
Я как раз утверждал, что язык и компилятор — единое целое.
Что, собственно, и является грубой ошибкой. У каждого компилятора есть куча особенностей, которые использовать нельзя.

Например первые компиляторы располагали переменные в стеке подряд и если вы писали
int a[4], b;
то вы могли обращаться к b, как к a[4]. Но частью это языка не было и поломались, в общем, довольно скоро. А ещё там можно было к intу прибавлять единичку пока не получится -1 — но, опять-таки, в стандарте это запрещено и в современных компиляторах не работает.

Да, компилятор, несомненно, описывает некоторый язык — но это не C! У него есть много свойств, которые в спеку не входят и полагаться на которые опасно. Потому что завтра, даже просто на другой машине, компилятор может повести себя по-другому — и вы получите кучу проблем.

А вот спека — она неизменна. Не зависит ни от машины, ни от желания левой пятки разработчика компилятора.

Изначальное управляемое видением автора языка, теперь — стандартом.
В любом компиляторе, всегда, есть вещи, которые туда автор не планировал закладывать — но они там есть. Просто «потому что так получилось». Опираться на них нельзя. Вот поэтому язык — это, в первую очередь, спека, а во-вторую компилятор.

В других языках (скажем Java) прилагаются очень серьёзные усилия к тому, чтобы программист не смог «усмотреть» в компиляторе чего-то, чего нет в спеке, в C/C++ — такие усилия не прилагаются. Правильная программа, соответствующая спеке — обязана работать, неправильная — тоже может работать, но что она, при этом будет делать — разработчиков не волнует от слова совсем. И это принципиальная позиция разработчиков. Потому в Java можно сказать, почти не покривив душой, что компилятор и язык — это одно и то же, но в C/C++ — нельзя.

13 самых заминусованных статей минувшего года

0
А откуда вообще взяалась уверенность в том, что эта проблема вызвана «медиарекламой» и никакого отношения к реальности не имеет?

У меня мать в 70е в ВЦ работала. И они там получали возможность запускать программы один, иногда два часа в неделю (некоторые — чуть больше). А остальное время — программы к этому готовились. Рисовались блок-схемы, проходила отладка программ «в уме», вот это вот всё.

То есть 10% успеха — заключалось в том, чтобы «что-то» придумать, а 90% — чтобы это «что-то» аккуратно и без ошибок реализовать. Это — в принципе, идеальная работа для женщины. Очень похожа на работу машинисткой, да.

А сегодня — никакой проблемы запустить написанную программу или даже набрать её — нет вообще. Если вы опечатались — то вам не нужно выкидывать перфокарту и «перебивать» её заново. Работа объективно, вот совершенно объективно, поменялась. 90% её — это что-то придумать, а реализация придуманного — это 10%. Никто уже не рисует блок схем и никому не нужно умение аккуаратно превратить блок-схему в программу.

Для женщин — это не характерно: они вообще не склонны выделяться. И скорее склонны использовать готовые рецепты, чем придумывать их. Генетика.

И что тут могут изменить «розовые питон-курсы»? Я знаю что: когда выяснится, что «медиа-проект» ничего не изменит — никто даже на секунду не задумается над тем, что уменьшение процента девушек может быть вызвано объективными причинами.

Начнут придумывать другие способы их привлечь — заставляя уже имеющихся программистов (мужчин, как понятно, иначе проблемы бы и не было) — заниматься всякими странностями типы выяснения того, как нужно кого-то звать (я не издеваюсь — сюда посмотрите).

Нафига всё это нужно? Ну не хотят девушки идти в программистов — наймите индусов. В Индии их полтриллиона. Дешевле выйдет.

Анализ сишного Hello World

Анализ сишного Hello World

0
Десять лет назад, когда я на эту штуку впервые набрёл (или примера из 20012го года ещё не было) — это было ещё смешнее.

Особенно «Note the lack of semi-colon. Improvement!»
1 There