megalol
+1
>Меня (как и всех кто учил существующих программистов) обучали алгоритмизации по блок-схемам и языку низкого уровня
Синдром утенка.
>паскаль, си (без плюсов), бэйсик, фортран.
>бэйсик
Лол. Классно научили, значит.
megalol
0
>Иметь возможность в браузере самому писать алгоритмы, в принципе, полезна. Но практически даром никому не нужна.
Мне нужна. Кому платить?
megalol
+6
Повторю здесь то, что писал в опросе: Crash 1 — шедевр прежде всего программирования (тот же Mario 64 вышедший на 2 месяца раньше, по графике и рядом не стоял, хотя N64 более продвинутая по железу), а вот геймплей они допилили уже во второй версии, в нее и третью нужно играть. Мемуары разработчиков очень интересны: all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1
megalol
+6
Зачем изобретать менеджер окон, когда менеджер окон встроен в ОС? Если я хочу параллельно с чатом посмотреть паблики, ютуб или пост на хабре, я просто поделю экран пополам. Текущий дизайн Вконтакте не пытается быть кабиной Боинга, чем приятен. Не туда весь этот дизайн для больших разрешений идет, ой не туда.
Хотя в рамках этой парадигмы работа сделана неплохо.
megalol
0
>Почему в этой истории не учитываются рубли за которые банк покупает у вас доллары? Чтобы купить у вас 900 долларов, банку нужно иметь 900 долларов в рублях. Нет?
Потому что история о печатании долларов. Если убрать доллары из рассмотрения, то останется то, что написал я. Вообще это называется «банковский мультипликатор» и на соответствующей статье википедии можно прочитать, что это. Важно понимать, что растет именно денежная масса, а не денежная база. В этом суть банков — деньги не лежат мертвым грузом под матрасом, а работают, что позволяет обойтись малым количеством денег, пока все думают, что у них на счетах этих денег много.
megalol
+1
Не стоит получать знания из фильмов, особенно таких, вообще не тот формат, чтобы что-то понимать. Весело написано про деревню Гадюкино у Авантюриста (http://bulochnikov.livejournal.com/13590.html), про банки — это история#1.
Если коротко, то так как банк деньги со вкладов выдает в виде кредитов (в простейшем средневековом случае он с этого и живет), то если кредитные деньги возвращаются обратно в банк, возникнет ситуация, когда у банка на вкладах 5000 рублей, банк выдал кредитов на 5000 рублей, а реальных денег в обороте 1000 рублей — просто они много раз клались на счет и были выданы в кредит. При этом понятно, что если все вкладчики попрутся в банк, он упадет, так все деньги он раздал в кредиты. Поэтому государство в таком случае важным банкам может дать дает кредиты в миллиарды денег. Но если банк функционирует нормально, то кредиты возвращаются, а значит и вклады тоже.
И вот эти деньги на вкладах — называются агрегатом М2 (https://ru.wikipedia.org/wiki/Денежная_масса). А простые реальные деньги — агрегат М0. M2>M0, причем чем больше это величина, тем лучше банки занимаются своей работой по финансированию населения.
megalol
0
>Я, кстати, наблюдаю такую тенденцию, что на россиийских заводах делают (стараются во всяком случае) такие штуки самостоятельно (и лучше себя, любимого в общем-то никто не сделает), а вот в европе видимо невыгодно держать на заводе специалиста «широкого профиля», поэтому такие системы заказывают на стороне «под ключ». Квалифицированная рабочая сила сильно дешевле высокотехнологичных продуктов, особенно импортных и особенно сейчас. Это плохо, конечно. Но тут что есть то есть. Я сомневаюсь, что завод по производству крышек для банок в Германии в принципе способен себе позволить держать специалиста по машинному обучению уровня siemdi даже если бы хотел. Хотя надо сказать, по моему опыту в США бизнесмены попроще, чем в Европе, так что дело не только в ненастроенной российской экономике, но и немецком менталитете. Хотя может я как фрилансер-одиночка просто с очень продвинутыми и бедными общаюсь — но в Европе таких в разы меньше все равно. >Ну а если в систему стоимостью несколько десятков тысяч евро поставить вебку с малинкой, то конечный заказчик… ну в общем будет несколько недоволен Ну конечно это чисто «для себя», даже в России. Но можно заказать какую-нибудь OEM вебку и запаковать ее в корпус, а разницу положить в карман. У меня есть пример еще хлеще — нам требовались конкретные диоды с диаграммой направленности 120 градусов, а не 30; на уровне полностью рабочего прототипа это решается спиливанием эпоксидной линзы (итоговая цена сто рублей за пучок), но этот колхоз в космический прибор не поставишь, так что требовалась официальная доработка. Завод-изготовитель заломил по-моему два миллиона за ОКР, а других сертифицированных изготовителей и нет. А с такой ценой можно было уже начинать думать о японских лампочках… Правда, с их паранойей по поводу военного применения это по-моему тоже не взлетело и бабло ушло в Томск. В общем, несколько миллионов за то, что можно в гараже сделать за рубль пучок — и при полной функциональной эквивалентности! А есть и обратный пример, когда реверс-инженеринг раствора для напыления родия сэкономил кучу денег.
megalol
+2
Да штуки хорошие, но цены — 1800 евро за младшую модель 640х480, это около месяца работы специалиста в России. За половину этой суммы и неделю времени можно сделать решение из бытовой вебки и raspberry pi в едином корпусе, если хочется чего-то типа втыкнул-и-забыл. Вот когда нужен объектив нормальный, наверное нужно будет раскошелиться. Я, кстати, так делал, делал контроль изображения солнечного имитатора из вебки, дискеты (светофильтра), скотча и пластилина. Провел нужные исследования и забил. Сначала хотели закупить промышленные камеры, но я узнал все так за несколько часов — а камер по-моему и через полгода так и не было из-за бюрократии.
megalol
0
>Максимальная ликвидность и обязательность всё равно есть только у наличных денег.
Как вы думаете, почему существует термин «отмывание денег»?
megalol
+1
Пробежался по комментам, вы принципиально название страны с маленькой буквы пишете?
megalol
+1
>С нормальным электронным государством, деньги гражданина или компании должны быть циферкой в БД центробанка, а денежный перевод должен делаться двумя командами SQL UPDATE.
Банки существуют для того, чтобы переиспользовать деньги. Он выдает кредиты из тех денег, которые ему принесли как вклады. Поэтому
«деньги гражданина или компании должны быть циферкой в БД центробанка» означает только то, что в стране есть только центробанк и никакой банковской системы.
А в нашем же капитализме у банка «на счету центробанка» вообще не быть денег не считая некоторого неснижаемого резерва. То есть если кто-то приходит в банк и говорит перевести миллиард в другой банк, этому банку придется влезть в долги, потому что вклад клиента он где-то прокручивает. Это и есть «более серьезная проблема – ликвидность».
megalol
+6
Зачем заставлять читающего постоянно кликать спойлеры с одним предложением? Неужели не нашли другого способа сделать отступление?
megalol
+3
Ну как же на несколько часов, если большая часть работы в виде монтажа и подбора освещения никуда не денется. То, что автор несколько ночей парился с алгоритмом скорее всего просто неудачный выбор С++ как языка прототипирования, в нем цикл проб и ошибок довольно затянутый.
А так работы с такой камерой не меньше, зато вместо зарплаты собственному работнику бабло уходит солидным дядям с солидным vendor lock-in. В общем, мечта откатчиков из отдела закупок.

И чтобы два раза не вставать, по-моему освещение диодами, покрытыми матовым стеклом и расположенными слева-сбоку, сработало бы лучше — на фото свет бьет прямо в промежуток, ухудшая контраст, а здесь бы подошло рассеянное освещение, аналог микроскопии темного поля.
megalol
+1
Вот тут кратко перечислены методы events.yandex.ru/lib/talks/1809/
Описанный в статье не подойдет — он полагается на частоты и временной интервал между ними, которые в разных исполнениях будут слегка разные, а нужно полагаться на ноты.
megalol
+3
Если образец один, то особых проблем нет — ищи себе взаимную корреляцию как вы, и все довольны — устойчивее сложно придумать на самом деле. Но когда образцов тысячи, то сложность O(n) уже не подходит и нужна индексация, которую с корреляцией не построишь. И тут подход с поиском «интересных точек» и обратным индексом {частота_интересной_точки => имя_файла} позволяет ускорить поиск до приемлемых величин. То есть мы находим «интересные частоты» в звуковом потоке и ищем файлы, которые эти частоты содержат, в индексе, а далее выбираем файл, содержащий наибольшее число интересных точек.

Лучший подход — комбинированный. Сначала отфильтровать обратным индексом до пары десятков-сотен кандидатов, а потом посчитать честную корреляцию (лучше на GPU). В массовых приложениях типа Shazam такой подход не используют, чтобы не грузить серверы.

Такую штуку легко построить на основе Echoprint, отредактировав его python api в части отбора лучших кандидатов.
Там в качестве поиска по индексу используется банальный текстовый поиск с помощью Apache Solr. Чем больше «интересных точек», тем выше Solr ранжирует «документ». Solr выдает большой список кандидатов, содержащих интересные точки. Далее в github.com/echonest/echoprint-server/blob/master/API/fp.py#L143 из этих кандидатов выбирается лучший. Каким образом? Таким github.com/echonest/echoprint-server/blob/master/API/fp.py#L262 — то ли строится гистограмма как в статье, то ли еще как, нужно читать код, я уже не помню. Но это не важно. Ничто не мешает или самому делать запросы к Solr или же переписать best_match_for_query, добавив туда «временную» корреляцию, доставая wav образца откуда-нибудь из базы (так как сам echoprint хранит только отпечатки). В итоге поменяв сотню строчек отбора кандидатов, и без написания своего codegen и API, можно получить систему, удобную лично для себя.
megalol
0
В том-то и дело, что система типов в хаскеле требует определенный стиль разработки — сначала семь раз отмерить, какие тебе типы нужны (ADT или кортежей достаточно? а тут у нас список или словарь нужен? или два словаря?), а потом отрезать код. А я предпочитаю скульптуры не из каменя высекать, а из пластилина лепить. Вылепил, а дальше прибил гвоздями типы с помощью аннотаций. В этом плане мне больше всего нравится язык Clay, в котором я даже поучаствовал немного, ныне застывший.
megalol
+2
>Про unsafe_string тут опять не понятно, при чем тут типизация
При том, что в статике тебе не нужно тестов, чтобы проверять эти случаи. Вообще. Если забыл где-то — оно не скомпилируется. И так как это бесплатно (что в плане производительности, что в плане затрат времени), этим можно пользоваться. Потратил время, а потом забыл.

>Вот смотри если ты не используешь TDD то программа у тебя упадет в любом случае, и тут никакая статическая типизация не поможет
Да нет, поможет. Хардкорное TDD вообще редко используют в статических языках, потому что не нужно. Тесты пишут уже после кода. Дилемма простая, в статике ты описываешь типы и пишешь мало тестов, а в динамике ты пишешь много тестов, очень много тестов, нужно больше тестов. И в чем профит, в экономии времени? Так в динамике время реально экономится, когда тестов не пишешь вообще :) А если их писать, то времени приходится тратить больше, чем на типы… Это хорошо видно по распределению проектов — динамика в основном используется как CRUD примочка к базе, которой упасть в принципе не страшно, для скриптов автоматизации, для прототипов и расчетов… А статика — когда куча умных перцев готовит проект на годы. И первоначальные затраты времени окупаются сторицей. Я ничего не проповедую, говорю как есть просто. У меня специфика такая, что я за динамическими языками провожу больше времени, мне холиварить вообще не о чем.
>На деле таких ошибок почти никогда не происходит.
Ну это легко проверить, посмотрев на багтрек любого проекта.
>Зато я постаянно вижу стэктрэйсы от всяких API на Яве, в том числе в досаточно серьзеных проектах.
Я написал выше, ява очень часто вынуждает динамически кастить типы, этот язык не совсем показатель.
>Почему-то не спасает их статическая типизация.
Но это и не панацея, но вопрос же не стоит «зачем мучиться со статикой, когда есть такая хорошая динамика». Патчить зрелый статический проект, в котором все типы давно написаны, намного приятнее, чем ковыряться в динамическом проекте в 10 раз меньше. Писать с нуля проще и быстрее скриптами…
megalol
+1
>Забавно, вы в предпоследней реплике, например, пишете чуть не дословно то, что в последней реплике обзываете «языкосрачем».
Я не против языкосрача, я против унылых аргументов. Когда идет аргумент, что на php можно сделать, ну да — вот github.com/ircmaxell/monad-php, но кто в здравом уме будет это использовать.

use MonadPHP\Identity;
$monad = new Identity(1);
$monad->bind(function($value) {
return 2 * $value;
})->bind(function($value) {
var_dump($value);
});

Функциональное программирование, это же не просто комбинаторы комбинировать а-ля linq to objects, как во времена SICP, в функциональной среде постоянно рождается что-то новое, что переходит в мейнстрим, сейчас это куча дополнительных фич и принципиально другой способ кодирования, который на императивных языках выльется в кашу из лямбд и тернарных if'ов вместо паттернматчинга.

>Не знаю, как вы, а я ни разу не сталкивался с проблемой «все сломалось из-за ошибочного типа».
А это не всегда видно, что типы могут помочь. Например, от всего пласта XSS ошибок и sql-инъекций в статическом коде можно избежать парой классов, но если рассуждать, что все строки одинаково полезны — уже не получится. От пласта ошибок единиц измерения, от которых ракеты падают, между прочим, тоже можно типами.
Но здесь дилемма статика/динамика непринципиальна (любые статические типы можно проверять и в динамике, и падать в рантайме), а вот сам факт падения при компиляции штука очень нужная и полезная.
megalol
+2
Могу более жизненный пример дать, от Джоэля. Два типа unsafe_string, и safe_string, первый всегда получается от юзера, и может потенциально содержать XSS, инъекцию или что-то подобное, а safe_string — безопасная строка. safe_string неявно конвертится в unsafe_string, а unsafe_string в safe_string нет, только методом escape. Все функции, работающие с пользовательским вводом, возвращают unsafe_string. Все функции, кладующие что-то в базу или выводящие принимают safe_string. В итоге компилятор сам следит за тем, чтобы не было вредного кода в пользовательском коде, программист забыть не может.

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

Вот чтиво про тесты в статических языках:
spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/
spin.atomicobject.com/2014/12/10/typed-language-tdd-part2/
megalol
+3
>Какая разница, упадет в рантайме, или при компиляции?
Огромная. При компиляции оно упадет при мне, а когда падает в рантайме — ну, если повезет, выловит тест, но раз в год и палка стреляет, а реальные люди почему-то отличаются от отличников из книжек по TDD, особенно когда сдача проекта вчера.

>А с изменяемым состоянием трубу не написать, что ли?
Я пишу «Читать код удобно», а вы мне что? Можно зделоть? Не понятно, о чем разговор, любовь к неизменяемости вообще с функциональностью слабо связана. const везде писать и в C++ рекомендуют, и у Макконнелла что-то подобное есть.

>В оригинальном тексте автор боится, что между map и reduce какая-то злая инопланетная тварь ему коллекцию испоганит. Это надуманная ерунда.
В оригинальном тексте много надуманной ерунды, да. Но это больше из-за вводного формата статьи. Сейчас из функциональщины взято все, что может быть легко перенесено в императивные языки, и поэтому особо такие статьи не впечатляют. Ну лямбды, ну вывод типов, а у нас вон linq и var есть. А на Rust если посмотреть, там и тайпклассы, и паттерн матчинг. Теперь впечатлять могут только вещи, которые уже так просто в императивный язык не перенесешь, потому что там все завязано на особенности этих языков. Типа vector fusion в хаскеле. А Scala лучше Java прежде всего как императивный язык, многие ее хотя бы из-за этого выбирают.

>На простом php можно запросто писать используя только функциональный подход.
Совсем унылые аргументы языкосрача пошли. Ну делойте, раз можно зделоть, вас кто-то насильно скалкой кормит что ли.
megalol
0
Тогда приходится тратить время на редактирование «спецификации» типов, которая вполне может пожить и в голове. Редко когда с самого начала угадаешь с типами. Конечно, если не угадал, то и код нужно переписать, но только по месту использования, а не в двух местах.
А так 'Нет ничего более постоянного чем временное' тоже работает, если проще 100% покрыть тестами, проще покрыть тестами. В общем, такие языки позволяют использовать динамику, там где это удобно, и статику где удобно. Пишется полно всякого обслуживающего кода — отчеты там всякие, и тут можно один язык использовать. В случае С++ приходится тягать функции из питона через SWIG или заниматься прочей ерундой. На JVM полегче, но все равно один язык довольно больше удобство.
megalol
+3
Всмысле «не заметить очень трудно»? Упадет в рантайме и привет. А опечатки возникают при мерже в git, например — это не всегда перед глазами. Приходится писать тесты на то, на что в статическом языке тестов не стал бы писать, потому что и так все работает.

В неизменяемом состоянии просто то, что если конструктор правильный, то состояние сущности всегда правильное. То есть конструктор и методы можно оттестировать отдельно, а в случае изменяемого состояния результат теста может зависеть от порядка вызова методов — что, естественно, никто в жизни тестами не покроет. Читать код удобно тоже — функции превращаются в трубы, которые преобразуют сущности.
megalol
0
Это не так долго, если выставить типы у корневой функции, то они выведутся сверху вниз до самой нижней. Если возникнет пара неоднозначных мест, можно пофиксить. Но изначальный код пишется в динамике, и мне это нравится больше, чем хаскельный подход с «сначала полчаса думаем, какие у нас будут типы».
megalol
+3
Грамотное применение типов может уменьшить число тестов в разы. Зачем мне делать assert(x.length=y.length), если у меня по системе типов в функцию передается список пар [(x,y)]?
Лично я за языки с опциональной типизацией типа Groovy, Julia или в какой-то степени Clay и шаблоны C++, а не за Haskell и Scala, потому что это позволяет сначала сделать динамический прототип, а потом отрефакторить, расставив типы, но это вопрос такой. Совсем без типов тяжко.
megalol
+5
Основное преимущество — статическая типизация, не нужно писать тесты на такие мелочи, как опечатки, и в целом увереннее себя чувствуешь, если скомпилировалось, значит, скорее всего, будет работать. Оно и в Java так, но в Java постоянно нужно обходить несовершенства системы типов, а здесь с этим попроще.
А неизменяемое состояние хорошо своей простотой — меньше сущностей при чтении кода, проще работать.
megalol
0
Не, у меня адблока нет, достаточно просто обновить
megalol
+1
Ну явно хорошее, если legacy побеждает. Вообще, любое решение по поломке обратной совместимости, обрекает тысячи незнакомых людей на лишнюю работу, а люди не любят делать лишнюю работу даже во имя чего-то светлого и великого типа функции print вместо оператора.
megalol
+2
Многие так рассуждают, а побеждает все равно С++ и python 2.
megalol
0
Ну а скупит кто? Тот, у кого есть деньги. А у кого есть деньги? У все тех же банков.
В общем, процесс такой. Преступник создает очередную популярную нелегальную биржу, она работает, государство ее прихлопывает. У государства гигантский объем монет, которым оно может спекулировать рынком, безо всякого майнинга. И как только форк становится популярным, так и будет. А непопулярный форк мало отличается от хавалы.
Гики очень наивны в плане восприятия циничности этого мира и мотивации действия государств.
megalol
0
Довольно плохо начинать оппонировасть с фразы типа «чушь», я в такие игры не играю. Очередной революционер сознания блин.
megalol
0
Он всегда будет малым — для крупных инвестбанков и рынок зерна вполне поддается манипуляциям.
Вы, конечно же, имеете в виду то, что эмиссия ограничена, но тут дело не в эмиссии (спекулянты и доллары не печатают), ничто не не мешает скупить биткоины или ограбить очередной silk road (очень важный звоночек — государство ловит преступников и аггрегирует много биткоинов), чтобы пошатать рынок во имя собственной выгоды. И риски тут намного выше, чем при переводе свифтом.
megalol
0
Бесконтрольно как наличка, но при этом без недостатков налички в плане необходимости физического перемещения. Можно минимизировать налоги, можно купить наркотики закладкой. Собственно и все. «Дешевизна транзакций» — это не технический вопрос, с точки зрения техники централизованная операция «вычел из одной переменной и добавил к другой» еще дешевле. Банки-клиенты централизованные тоже удобнее.
Как видно, для государства нет преимуществ никаких — одни недостатки. Но в развитых странах в целом пофиг — у них и так NSA слушает все, что можно, да и систему можно использовать для себя (например, финансировать своих агентов за рубежом). В России же хотят запретить — хотя это ничем не поможет в общем-то, потому что ничто не мешает обналичить деньги за рубежом и перевести сюда уже на счет. В общем, в разных странах подход разный, но цель в виде контроля над обществом все равно выполняется так или иначе.
megalol
0
Дефляция была всю историю человечества. Экономика в этом случае останавливается, потому что людям не выгодно тратить деньги. Оптимальнее небольшой инфляции ничего не придумали.
megalol
0
>Второе преимущество — курс.
>Десять долларов осенью и десять долларов зимой — это разные деньги.
>Биткоин не подвержен геополитическим дрязгам и махинациям на цене нефти.
Биткоин подвержен махинациям как любой другой финансовый инструмент, причем, учитывая размеры рынка, подвержен гипермахинациям, что и наблюдается в его курсе. Если я продам бочку нефти сейчас и куплю биткоины, сколько нефти я куплю через год? В случае долларов я хотя бы знаю, что ну полбочки, если не повезет, а может и две бочки. А биткоин может и в 5 раз скакануть, как было не раз.
megalol
+1
Откуда японцы вещают, что их в Рязани можно поймать?
megalol
–2
Можно зарегистрироваться на qiwi visa virtual с парой долларов на счету — будут пытаться снять деньги где-то полгода и все это время можно будет пользоваться бесплатно. Открыл случайно.
megalol
+1
Мапл умеет непростые формулки нормально отображать, работать с символьными вычислениями мне больше нравится
megalol
0
Это легко обходится анонимайзерами. Ничего лучше силы воли тут не придумаешь.
megalol
–1
Я на best-proxies списки прокси покупал. Наверное их можно и бесплатно найти, но за те копейки и удобную выдачу, почему нет.
Насчет Москвы не знаю, в городах типа 500К квартиры лучше вручную искать, на рынке не так много предложений, а на поиск жилья, в котором будешь жить не менее года, лучше потратить время.
megalol
+5
Эквалайзером можно было высокие частоты у звуков прибрать, звучало бы более казуально