Мысль, что в программировании математики больше, чем в филологии или в ботанике, обманчива.
Не менее, чем представление о том, что эта мысль была кем-то высказана:) Вы с кем спорите-то? Я не вижу тут ветряных мельниц.
Суть математики как раз в том, чего нет в программировании, в физике, и прочих биологиях — утверждения в математике либо признаются без доказательств бесспорно истинными аксиомой, постулатом, принципом, либо истинность каждого утверждения строго доказывается.
Я не знаю, что Вы считаете математикой, что это её суть. Я уж не говорю о том, что некоторые основания математики в принципе недоказуемы, и это доказано, что их нельзя доказать (!) - в результате то, что мы используем, является результатом общего соглашения, направленного чисто на практические результаты. Почитайте хотя бы в общем результаты Чёрча, или что такое континуум-гипотеза. Да даже в элементарной геометрии мы имеем такие допущения — аксиома про параллельные, которая не обязана быть верной.
Математика сама по себе — это сферическая логическая игра в вакууме. Смысл ей придаёт связь с реальностью, с описываемыми явлениями. А качество этой связи — есть вопрос качества той модели, которая применяет математику.
У нас есть понятие «равенство». Оно само по себе предполагает определённые ограничения на его результаты. Если A == B, то должно быть B == A. Да, это не математика как таковая. Математику совершенно нет проблем определить такое «равенство», которое антикоммутативно или зависит от стохастического фактора. Вопрос только — накойхер это делать? И если вы определяете нечто, что названо «проверка на равенство», но оно не соответствует ожиданиям от отношения равенства — тут есть два варианта: или написать об этом огненными буквами на всех стенах (как приходится делать пишущим на PHP или JS), или переименовать его в более подходящее имя (как делают в качественно проектируемых языках). Например, сюда хорошо подходит «is», принятое в Питоне, или «=~» из Перла (если не ограничивать его regexp’ами).
то такое программа? Это просто математическое уравнение, состоящее из длинного-предлинного полинома в натуральных числах.
А ещё это арбуз, заполненный семечками в определённом порядке. А ещё я могу её сравнить с поэмой или с ветром. Какой смысл в таком сравнении?
то записать программу математик мог бы лишь после ее доказательства.
Есть понятие математической верификации программ. Есть языки, подготовленные к этому существенно лучше остальных. Есть задачи, под которые обязательно писать с верификацией. Но всё равно код такой программы вначале придумывают, а потом доказывают. И не бывает так, что вначале докажут без кода, а потом пишут, что же именно доказывали:)
[пропустил остаток потока сознания, который не относится к теме никоим образом]
Язык для программирования это средство для передвижения.Вот я и не представляю у труЪ шофера лютую ненависть к тому или иному средству передвижения. Посокрушается о недостатках и неудобствах, поворчит, но раз сказали «едем на этом», значит, едем «на этом»
Нет, уважающий себя шофёр просто откажется ехать на том, где ему не хватает обзора или где колёса норовят отвалиться на ходу. Он скажет — начальник, или давай нормальное и целое ТС, или иди нафиг. И только программист позволяет себе ездить на постоянно рассыпающейся таратайке — но только до тех пор, пока он действительно не начинает отвечать за ошибки, хотя бы частью заработка.
наверное, про явное и неявное приведение типов слышит впервые.
Неявного должно быть минимум, и не давать неожиданных эффектов при перестановке. А явное по определению даёт и коммутативный, и транзитивный результат.
может, тогда большинство полагает, что у всех операторов одинаковый приоритет?
Я не могу понять, что в моих сообщениях дало основание к таким предположениям. Но, видимо, это и неважно, поскольку оно таки не предполагает таких странных идей:)
нынче в программировании никакой математики нет.
К сожалению или к счастью, но она есть. Более того, если выгнать её через дверь, она вернётся через окно, причём в самый неподходящий момент и самым неожиданным образом.
Я не против каких-то хитрых правил сравнения, если они действительно окажутся полезными. Но: 1) по POLA, если вы применяете знак «==», то большинство уже предполагает, что данное сравнение будет как минимум коммутативно и транзитивно; 2) вводя свои правила, надо их придумать так, чтобы они были хотя б сами с собой согласованы, а не то, что мы видим. А знаков потом можно много применить, см. например подход Perl6.
А вот настоящий программист не будет плохо отзываться о любом языке. Ему же всё равно, на чем написать программу.
Увы и ах, не согласен. Представьте себе «Запорожец» с колёсами от БелАЗ’а, но с тем же двигателем, причём второй багажник приварен так, что закрывает водителю половину обзора вперёд, а омыватель лобового стекла разворачивает стекло, поливает всё в салоне включая водителя и затем поворачивает стекло обратно:) Будет водитель радоваться такой машине? При полном отсутствии других и возможности переделать — да, сидя в водолазном костюме с электроподогревом и ругаясь сквозь зубы:) Но в цивилизованных условиях он первым делом постарается добыть взамен L200, предполагая задачу возить картошку на продажу:) Так и тут — Javascript в нынешнем виде аналогичен тому запорожцу и живёт только за счёт монополии. И то — очень много любителей использовать его только на нижнем уровне, как ассемблер, а сверху громоздить что-то своё.
Вот я недавно батничек писал, и там всё как положено, вызовы, проверки, аргументы.
Ну я почти каждый день пишу батники (только на юниксовом шелле, а не виндовом), а при чём тут они? ;)
YAML. никогда не понимал причин его пользования, когда есть hash + Storable
hash+Storable мне не помогут, когда получатель на другом хосте и не на Perl, а на Python. Тут годятся только языконезависимые форматы. Ну а YAML или JSON — решено было уже по месту и по вкусу.
когда силами «умельцев» в коде появляется несколько тысяч глобальных переменных
Такую херню можно сделать на любом языке... мы даже на Erlang’е такое сумели:) Это всецело вопрос культуры разработки.
а юнит тестирование отсутствует в принципе
Вот за это и следовало бить виновников по наглым рыжим мордам.
чем было ранее в перловом проекте, разработанном силиконо-долиновыми пиндосами
Да, write only это страшная сила:( без полного рефакторинга и не начинать.
Я б не ставил perl «в один ряд с», кабы не одна ситуация — рассказываю именно в таком виде, как сам столкнулся, чтобы живее было:) VoIP свич, конфигуратор передаёт правила раутинга. Управляющий код на Perl, трансфер правил в YAML. Тестеры говорят «нихрена не работает», идём разбираться... тестовые префиксы номеров вида 000999 передаются в свич в виде... 999! Пока YAML dumper’у не сказали, что все скаляры считать строками, он не начал правильно посылать. Оказалось, что средствами самого языка нельзя отличить скаляр — число от скаляра — представления этого числа в виде строки... на уровне C и работы со структурой SV — можно, да кто ж туда пойдёт возиться. То, что операции разделены — уже хорошо — не такой кошмар, но невозможность различить типы скаляра местами очень вредит. А хохмы типа «0» как false, но «00» как true? Это из той же оперы:( В Питоне сделано лучше — любая непустая строка это true, а если предполагается число — зовите int() явно.
LOL, спасибо:))
Ценителю кривых недоязычков надо бы научиться различать строгую и статическую типизацию, чтобы не выглядеть банальным невеждой. Для работы данного примера нужна динамическая типизация. Динамическая типизация — это как в Python, Ruby, Erlang, LISP и ещё куче мест, где тип переменной не задаётся и может быть любым из известных, но операции с ним всё равно такие. какие позволены типу. А вот когда (хрестоматийный пример про JS) ’5’-3==2, но ’5’+3==53, это никакой динамикой не объяснить, это банальный бред, мокрая рваная тряпка вместо строгой типизации.
JS отвратителен не динамической типизацией, не поддержкой DOM, не JSON, не замыканиями и ничем подобным, но 1) слабой типизацией с непресказуемыми эффектами, 2) кучей дебильных решений по синтаксису, которые взрываются самым неожиданным образом, 3) аналогичных проблемах с библиотечными функциями. В этом он близок PHP (ещё один выбредок веба) и Perl, который всего лишь старался быть «лучший шелл, чем шелл, и лучший awk, чем awk», но его неизбежные проблемы были раздуты и подняты на флаг как принципиальные решения.
Простейшее гугление по «weird javascript feature» показывает сотни таких примеров. Вот небольшая выборка со StackOverflow:
2 == [[[2]]]
a[[[["abc"]]]] === a["abc"]
Сравнения — некоммутативные и нетранзитивные:
’’ == ’0′ // false
0 == ’’ // true
0 == ’0′ // true
false == ’false’ // false
false == ’0′ // true
false == undefined // false
false == null // false
null == undefined // true
" \t\r\n" == 0 // true
Неупорядочённый синтаксис разделения операторов, когда два оператора, валидных по отдельности, рядом через ’;’ становятся синтаксической ошибкой. Странные и неочевидные правила automatic semicolon insertion, при отсутствии возможности явно исключить его на стыке строк, как сделано во всех нормальных языках с построчным синтаксисом (Python, Occam, BASIC образца MS, и так далее).
Молчаливая конверсия между числами и строками с местами неочевидными и неуправляемыми правилами.
Восьмеричные константы по ведущему ’0′ и молчаливое игнорирование проблем с ними (parseInt("08″) == 0), а как общий подход для библиотеки — вообще тенденция на максимальное маскирование ошибок вместо показа их как исключений (опять-таки, общее с PHP и Perl).
Кривые правила видимости переменных (например, явно объявленная во вложенном блоке будет видна снаружи от него).
Возможность грязного хака с заменой значения для undefined, Infinity, NaN (общая проблема с PHP и старыми Питонами, но эти хоть в новых версиях такое правят).
Бездумное копирование свойств старых проблемных API (например, работа с датами — год минус 1900, январь как 0).
void как префиксный оператор.
Продолжать тут можно часами, мне надоело. Общее впечатление — язык разработан, мягко говоря, через пятую точку, фатально неравномерно и бескультурно. Его немногочисленные преимущества на этом фоне практически незаметны, остаётся только одно — что он хоть и четырежды дерьмовый, но уже стандарт.
«И как приятно, где нас нет, какая чистота...» :)
Вот про 99% и есть «мечты и домыслы». 90% — ещё готов поверить (учитывая реальный уровень запросов тех, кому компьютер нужен для ютуба и вконтактика), но вряд ли больше. А если учесть офисный мир, в котором по факту каждый второй компьютер, то может оказаться, что и меньше.
Через год всё увидим — расширение мира смартфонов уже остановится.
PC по любому не уйдёт в ноль, и вряд ли скатится ниже 10%. Просто из-за принципиальных ограничений характеристик карманного изделия по сравнению даже с лаптопом. А уж тем более классы типа «рабочая станция» и «сервер» останутся нетронутыми. А ещё надо учесть, что сейчас смартфон — это новая мода, и пока идёт поток запросов первичных обладателей. Когда он схлынет, будет некоторая регрессия.
Я вот жду, когда же авторы интерфейсов перестанут ориентироваться на телефон как основную цель и поймут, что десктоп надо делать иначе, чем телефон...
Ну уж... Кошмаръ аццкій циникъ, а Егор не станет таким хотя бы из-за религии. И это скорее хорошо — при всём опыте Кошмара он на моей памяти ни разу не выдал такого концентрата конструтивных утверждений и положительного опыта, который потянул бы хотя бы на два абзаца. (Для примера вспомним хабр — примитивизм последнего не так важен, как именно общая конструктивная направленность статей.)
Хм, логично:) По крайней мере соответствует вопросу.
PHP может быть неустранимым внешним требованиям. Некоторые, как я, могут позволить себе занять позицию «у меня PHP неприменим нигде и ни под какими условиями», но для веб-разработчика это проигрышная позиция. А статья очень хорошая, если Вам не понравилась — значит, Вы или гений и можете сказать лучше (и где тогда?), или нифига не поняли (тогда перечитывайте до просветления).
Ну я в 14 уже работал (первая реальная программа — драйвер графического адаптера для ДВК-3), и это ещё в
Уже смешно:)
Вы заняли первое место на районной олимпиаде по солипсизму.
Hint: Itanium.
А почему машина разработчика не должна быть надёжной? ;)
Пример с перевернувшимся битиком я уже приводил. Я пару раз такое видел вживую.
А прогонять всё через сборочный сервер с супернадёжным защищённым железом — не всегда возможно.
А ещё машина разработчика должна быть ровно такой скорости, чтобы его работа не тормозила, но не быстрее, иначе получится продукт известного типа, который нормально работает на железе минимум в 3 раза дороже бюджетного. Поэтому меня все эти гонки за процессорами для разработки удивляют.
А на самом деле у вас память битая, или конденсатор какой потек.
Пожалуйста, перестаньте путать кванторы. Я в этой дискуссии не рассматриваю потёкшие кондёры или битую память.
При том, что частота процессора и так была занижена производителем на 40% из маркетинговых соображений.
Примеры такого за последние лет 5 в основной линейке продуктов (не в Extreme и т.п.)?
"Синьор"-тестер это не тот,то по спецификации тестирует, а тот, кто сам тесты придумывает, а то и тестовые фреймворки строит. А Вы просто не разбираетесь в предмете.