>var barResult = CreateBar()
Это уже венгерская нотация. Собственно в нестрого типизированных языках она спасает, но зачем сначала добавлять в строго типизированный язык проблемы нестрого типизированных языков, а потом пытаться решать их с помощью таких вот костылей.
К тому же тут возникает опасная проблема с рефакторингом. Допустим захотел я переименовать Bar в AwesomeClass. Среда разработки любезно переименовала за меня типы. Последствия лучше показать на примере. Допустим у нас есть несколько вариантов одного и того же кода.
/*1*/ var barResult = CreateBar();
/*2*/ var barResult = Bar();
/*3*/ var result = Bar();
/*4*/ var result = CreateSomething();
/*5*/ Bar result = Bar();
Сравним результаты рефакторинга:
/*1*/ var barResult = CreateBar(); // Bar теперь AwesomeClass, но код не поменялся совсем, название метода и переменной теперь нагло врут
/*2*/ var barResult = AwesomeClass(); // уже лучше, но название переменной по прежнему врет
/*3*/ var result = AwesomeClass(); // все корректно заменилось, код не противоречив и не сбивает с толку
/*4*/ var result = CreateSomething(); // тип result не ясен, если не знать, что возвращает CreateSomething, но код хотя бы не врет
/*5*/ AwesomeClass result = AwesomeClass(); // все корректно заменилось, код не противоречив и не сбивает с толку, тип result очевиден
Вывод: поскольку var уже появился, и никуда от него не деться, придется к нему привыкнуть, но компенсировать его недостатки, кодируя тип в названиях переменных и методов — явно не стоит. Бороться с неявностью, которую вносит var, можно, разве что, уменьшая область видимости переменных, которые с ним объявлены. Если программист может легко охватить взглядом участок кода, от объявления такой переменной, до ее смерти, то тип ему будет ясен из контекста. Тем более, больших методов вообще лучше избегать.
Все же, в случае с КиноПоиском проблема была не столько в редизайне, сколько в том, что сначала был один сервис, а потом, под тем же названием, выкатили совершенно другой. Большую часть полезной информации с сайта просто убрали. Это был не редизайн, а вандализм какой-то. Ну либо я неправильно понимаю значение слова «редизайн». Для меня редизайн — это изменения, не меняющие функциональность. Конечно все не обязано ограничиваться тем, что был красный фон, а стал зеленый. Может меняться способ доступа к функционалу, но не его наличие. То есть спрятать поле поиска в выпадающее меню — это редизайн. А вот убрать это поле совсем — это уже не редизайн, а что-то другое. От этого кстати не только сайты страдают, но и, например, игры. Есть огромное количество примеров, когда в новой части игры, от старой остался только сеттинг.
>В моих США, конца XX века, компьютеры имеют 640 килобайт памяти, а мобильные телефоны размером с силикатный кирпич…
Не стоит недооценивать прогресс. За какие-то 30 лет, компьютерные технологии продвинулись настолько, что мы уже на полном серьёзе начинаем задумываться о роботах. О настоящих роботах. Еще несколько лет назад их вообще не было, а теперь они уже сами ходят. Их пинают, а они не падают. Сбивают их с ног палками, а они снова встают. Уже сегодня пресловутый искусственный интеллект классифицирует наши личные фото в социальных сетях. А распознавание голоса? Я регулярно пользуюсь. Это уже повседневная жизнь. А вы говорите лично не коснется. Уже коснулось.
Ну на первый взгляд, вполне подходящая плата. Непонятно только что у нее с софтом. Есть какие-то ссылки на образы Linux и Android, но судя по размеру (Linux — 100mb, Android — 8mb), там что-то странное. Мне нужно чтобы был рабочий стол и браузер, иначе где я WebGL показывать буду. Или я что-то не то смотрю? Смотрел здесь
Да ну, разве выбор профиля это сложная настройка? Просто дома мне будет показываться одна реклама, а на работе другая. Не думаю, что с несколькими профилями будет намного сложней что-то прогнозировать и пропихивать. Зато пользоваться будет удобней, а значит пользователей будет больше. Плюс больше вероятность того, что пользователь «в нужном настроении», для соответствующей рекламы. То есть она будет еще более таргетированной, а следовательно более эффективной. Вы только задумайтесь, такого еще ни у кого нет. Все собирают информацию о том, к чему пользователи проявляют интерес, но никто не учитывает, когда и при каких обстоятельствах они это делают. Ведь реклама горящих туров в рабочее время может напрочь сбить с рабочего лада. Да и вообще, наличие в ленте, в рабочее время, чего-то не относящегося к работе, может свести продуктивность к нулю. Решений я вижу два: либо сервис угадывает, не только, что мне интересно в принципе, но и что мне интересно именно сейчас, либо добавляем возможность вручную выбирать профиль: рабочий, домашний, семейный, ночной и т.д. Возможна так же комбинация двух этих методов — что-то доверяем угадывать сервису, а что-то определяем вручную, выбрав профиль. Собственно, именно это я и предложил в своем первом комментарии. А кому несколько профилей не нужно — будут сидеть с одним по умолчанию, то есть и усложнения не заметят. Вообще никаких минусов не вижу, ни для пользователей, ни для компании.
Ну вообще я говорил про фильтры, которые вкручиваются в кувшин. Эти через месяц становятся бесполезны практически.
Вот, ради интереса посчитал стоимость использования первого попавшегося осмосного фильтра. Может быть можно и существенно меньшими деньгами обойтись, просто некогда сейчас искать.
Аквафор DWM-101S Морион: 7900 р.
Модуль K5 — Механическая очистка воды. ~ 3-6 месяцев (290 р.) = 580-1160 р/год
Модуль K2 — Доочистка воды. ~ 3-6 месяцев (560 р.) = 1120-2240 р/год
Модуль сменный мембранный К-50S — Глубокая очистка и умягчение. ~ 1 раз в 1,5-2 года (1990 р.) = 1000-1327 р/год
Модуль К7M — Финишная очистка воды и насыщение минералами. ~ 1 год (570 р.) = 570 р/год
Плюс само устройство, раз в 10 лет хотя бы менять = 790 р/год
Оптимистичный расчет: 580+1120+1000+570+790=4060 р/год = 78 р/неделя
Пессимистичный рассчет: 1160+2240+1327+570+790=6087 р/год = 117 р/неделя
На всякий случай ссылка, откуда я брал информацию о ценах и сроках замены частей: http://www.aquaphor.ru/filters/dwm-101s
Это примерная цена 10 и 15 литров бутилированной воды соответственно. В неделю. На одного это мне за глаза хватит. Я больше пяти литров в неделю не трачу обычно. Учитывая, что большую часть времени я провожу на работе, и там пью чай/кофе. Готовки тоже немного. Так что, даже если уложиться во вдвое меньшие деньги за фильтр, это все равно будет не дешевле, чем мне обходится вода в бутылках. На семью наверное выгоднее выйдет. А одному — не особо. К тому же, что будет, если я в командировку на пару недель уеду? Не зацветет ли вода в фильтре? Еще надо учесть такой вариант, что начал воду набирать в фильтр, и вдруг потекла ржавая. Не испортится ли он от такого? С другой стороны, может при моем темпе использования, менять модули придется реже, чем написано в характеристиках. Короче много нюансов. Очень многое зависит от разных жизненных факторов. Например, если поблизости негде купить воды в бутылке, фильтр будет просто удобнее. Говоря поблизости, я говорю о двух-трех минутах ходьбы, все же вода не такая легкая, таскать ее. Очень существенно на выбор может повлиять наличие автомобиля. Ну и т.д.
Главная проблема всех этих рекомендаций, такая же, как и у обычного окна с часто посещаемыми страницами. Все интересы валятся в одну кучу и не сортируются. Страница быстрого доступа помогает пользователю удобнее и быстрее серфить по любимым сайтам. Вы смотрите, что пользователю интересно и предлагаете ему похожее, на других сайтах. Но проблема в том, что пользователь это не константа. Он изменчив. Я не имею в виду, что человеку нравились боевики, а потом они ему надоели. Я говорю о циклических изменениях. На работе я интересуюсь одним. Дома — совсем другим. Придя на работу я лазил по Stack Overflow, и читал статьи на Хабре, пытаясь разобраться с React.js. А в обед я уже читаю и комментирую статью о новом Яндекс Браузере. Перед этим я почитал новости. Вечером я буду изучать английский язык, а потом, посмотрю какой-нибудь сериал, после чего залезу на сайт его обсудить. В выходные буду изучать Python. А когда ко мне приходят друзья, мы часто смотрим КВН на YouTube. И мне не нужно больше или меньше чего-то из всего этого списка. Мне нужно все это, но в нужное время и в нужном месте. И мне совершенно не нужно, чтобы открыв браузер перед начальством, в рабочее время, я засветил там свои «обеденные» интересы. Попробуй потом докажи, что это ты читаешь только в обед. Так что недостаточно изучать мои интересы. изучайте всего меня, мой распорядок, мои шаблоны поведения. Только тогда ваш сервис достигнет истинного просветления. А еще надо не забыть, что у каждого человека есть интересы, которые он не хотел бы спалить перед другими. Может быть стоит добавить возможность вручную переключаться между несколькими Дзен-профилями.
У меня дома вода из крана воняет железом. Вода, купленная в бутылке, железом не воняет. Так что, как минимум, по одному из параметров, бутилированная вода лучше. Можно конечно фильтр купить, но фильтры тоже не дешевые, и чтобы было эффективно, надо, хотя бы раз в месяц, их менять. Еще, фильтрованная вода из под крана цветет, когда долго стоит. Бутилированная — не цветет. То есть она уже кипяченая.
Так что бутилированная все же получше. По крайней мере, когда водопроводная — откровенно плоха. При этом я беру самую дешевую воду. В том, что вода, которая вдвое дороже, будет в два раза лучше, я сильно сомневаюсь.
Да, вы правы. Сейчас погуглил и нашел статью, где человек пишет, что проблема на Raspberry Pi с графическим драйвером. Там даже ссылка на экспериментальный образ ОС есть. Будем пробовать. А вообще, на Raspberry Pi 2, сама идея с браузером сносно работает. Скорость работы, в целом, приемлемая. Только WebGL выдает один кадр в несколько секунд. Раньше, когда искал инфу по этому поводу, везде находил только, что аппаратного ускорения WebGL нет, и решил что это ограничение на уровне железа.
На всякий случай, может кому пригодится ссылка (хотя, на данный момент, она первая в гугле по запросу raspberry pi 2 webgl): https://www.scirra.com/blog/ashley/23/how-to-get-webgl-on-the-raspberry-pi-2
Но в случае смеси ООП и ФП, иммутабельными придется делать не все объекты в программе, а только те, которые участвуют во взаимодействии между объектной и функциональной частью. Как-то так я себе это представляю.
Функциональные примеси, они не в ООП. Они в языках программирования. Это говорит лишь о том, что ОО-парадигма не является ответом на все вопросы. Тут вступает в силу старая добрая истина: «Используйте инструмент, подходящий под задачу.»
Языки программирования добавляют функциональные примеси для того, чтобы сделать язык более универсальным и удобным. Это вполне логично с их стороны. По этой же причине во многих языках высокого уровня можно делать ассемблерные вставки. По этой же причине, в C# можно добавить unsafe код.
Если топор не подходит для того, чтобы копать землю, и человек берет с собой, и топор, и лопату, чтобы сначала срубить дерево, а потом выкопать пень, разве это говорит о слабости топора?
Про объекты без полей, а следовательно и без состояния, я кстати уже упоминал где-то в этой теме. Да и метод, при этом, не обязательно должен быть один. Еще, как вариант, может быть неизменяемый объект. В этом случае, для методов объекта, его поля будут фактически константами.
Просто, как язык, позволяющий писать в обоих стилях. Да хотя бы тот же JS. Аргументы функции — объекты. Функция — тоже объект. В итоге, как хочешь, так и пиши. Ну или взять хотя бы MVC с активной моделью. View можно написать в функциональном стиле, а Model — в объектном. Controller, в зависимости от задачи, либо в функциональном, либо в объектном. Противоречия, они в основном идеологические. А чрезмерная идеологизированность на пользу не идет. Нужно искать компромиссы. К тому же, многое зависит от того, как вещи рассматривать. Можно ведь считать поля объекта неявными параметрами его методов. А сам объект, на протяжении его жизненного цикла, от конструктора до деструктора, можно воспринимать как функцию. В то же время переменные объявленные во внешней функции, для замыкания будут теми же полями. В некотором смысле внешняя функция, для замыкания является объектом, а само замыкание аналогично методу объекта. А раз, и объект можно считать функцией, и функцию можно считать объектом, то значит никакого противоречия между ООП и ФП нету. Это просто две разные абстракции, вокруг одних и тех же сущностей.
Ну почему же прямо для очень узких. К примеру сервер любой можно написать. Там как раз есть вход (запрос) и выход (ответ). А это, хоть и частный случай, но в то же время очень частый. Клиент-серверная архитектура распространена повсеместно. Графический интерфейс, как мне кажется, тоже можно писать в функциональном стиле. Для GUI вообще удобней всего использовать реактивное программирование, а оно очень хорошо реализуется с помощью ФП. Сюда же можно отнести любой рендеринг. В том числе и 3D рендеринг в играх. Физика в играх тоже хорошо в эту парадигму вписывается.
Вот уже получается, что ФП может найти свое применение, и на сервере и на клиенте, и в играх. И это не какие-то редкие случаи, не какой-то специфичный софт, а самые общие вещи: сервера, графический интерфейс, рендеринг, расчет физики.
Но будущее, на мой взгляд, за гибридным подходом. Сплав ООП и ФП, на мой взгляд, наиболее удобен с практической точки зрения.
Ну художник это прежде всего не тот, кто может нарисовать сисястого дракона по запросу, а тот, кто может создать что-то новое по своей инициативе. Я прямо так и представил, если бы Ван Гог жил в наше время. Ему на deviant art пишут, заказ: «Нарисуй звездное небо в синих и желтых тонах. Причем звезды должны быть таки ОГРОМНЫЕ, как перекати поле. Словно на фотографии с большой выдержкой. И свет от них по всему небу волнистыми линиями.» Вот только не было такого запроса, он сам придумал нарисовать именно это и именно так.
Да и не картинами едиными. Сможет ли нейронная сеть сочинить музыкальную композицию, наравне с Моцартом или Вивальди? Или написать книгу не хуже, чем «Война и мир»? Наверное когда-нибудь сможет. Но это будет уже ИИ, не уступающий человеку. Что тогда будет с людьми, я лично не знаю. Одно знаю наверняка — это будет уже совсем другой мир. Надеюсь человеку в нем найдется место. Ну а если нет, это будет значить, что мы где-то свернули не туда.
Кстати, сейчас вспомнил одну очень показательную историю. В 2006-м году, когда у меня появился безлимитный Интернет, и я хотел что-то скачать, не помню что именно, да и не в этом суть. Нашел это только на торрентах. Я тогда не знал что это такое. Скачал торрент-файл, открыл его блокнотом. Там были ссылки. Пробовал их вбивать в браузер, но ничего не получилось. На следующий день, когда пошел на учебу, а учился я тогда в колледже, на программиста, я стал спрашивать у всех в группе, что такое торренты. И никто не знал, хотя с компьютерами. конечно же, все были на «ты». Само собой, вечером я немного погуглил, а точнее порамблерил (да, да, тогда я пользовался рамблером), поставил себе uTorrent и скачал нужный файл. Это было 10 лет назад. Тогда мне казалось, что торренты это что-то такое очень гиковое, хотя если подумать, они и тогда уже были распространены. Это я о них тогда впервые узнал, т.к. жил не в столице и интернет до нас добирался долго. Но тогда я и представить не мог, что это достигнет такого размаха, как сейчас. Однако ж достигло. Вполне возможно, что и ZeroNet станет мейнстримом. Ну или что-то другое из той же оперы. Ведь распределенный сайт это выгодно не только для борьбы с блокировками. Это в принципе очень хороший вариант для всяких энтузиастов, которые делают некоммерческие сайты. Сегодня приходится, либо делать их себе в убыток, либо заморачиваться с рекламой или сбором пожертвований, только чтобы оплатить хостинг. Даже больше скажу, лучше всего будет, если распределенные технологии будут развиваться, прежде всего, как решение каких-то других проблем, а не цензуры и блокировок.
Допустим, написать софт для ИИ сравнительно не сложно. Но чтобы написать софт, удовлетворяющий бизнес требованиям, надо эти бизнес требования понять. Чтобы объяснить ИИ, что от него требуется, нужен либо достаточно умный ИИ, практически равный человеку, либо задание придется записывать в некотором формализованном виде. Таким образом программирование станет более декларативным, а ЯП будут, пусть и менее, но все же формализованными. Причем, чем умнее будет становиться ИИ, тем в более «человеческом» виде мы сможем объяснять ему наши требования. И где-то в тот момент, когда обычный менеджер сам сможет объяснить ИИ задачу, так чтобы тот его понял, станут не нужны ни программист, ни менеджер, ни люди вообще.
Это уже венгерская нотация. Собственно в нестрого типизированных языках она спасает, но зачем сначала добавлять в строго типизированный язык проблемы нестрого типизированных языков, а потом пытаться решать их с помощью таких вот костылей.
К тому же тут возникает опасная проблема с рефакторингом. Допустим захотел я переименовать Bar в AwesomeClass. Среда разработки любезно переименовала за меня типы. Последствия лучше показать на примере. Допустим у нас есть несколько вариантов одного и того же кода.
/*1*/ var barResult = CreateBar();
/*2*/ var barResult = Bar();
/*3*/ var result = Bar();
/*4*/ var result = CreateSomething();
/*5*/ Bar result = Bar();
Сравним результаты рефакторинга:
/*1*/ var barResult = CreateBar(); // Bar теперь AwesomeClass, но код не поменялся совсем, название метода и переменной теперь нагло врут
/*2*/ var barResult = AwesomeClass(); // уже лучше, но название переменной по прежнему врет
/*3*/ var result = AwesomeClass(); // все корректно заменилось, код не противоречив и не сбивает с толку
/*4*/ var result = CreateSomething(); // тип result не ясен, если не знать, что возвращает CreateSomething, но код хотя бы не врет
/*5*/ AwesomeClass result = AwesomeClass(); // все корректно заменилось, код не противоречив и не сбивает с толку, тип result очевиден
Вывод: поскольку var уже появился, и никуда от него не деться, придется к нему привыкнуть, но компенсировать его недостатки, кодируя тип в названиях переменных и методов — явно не стоит. Бороться с неявностью, которую вносит var, можно, разве что, уменьшая область видимости переменных, которые с ним объявлены. Если программист может легко охватить взглядом участок кода, от объявления такой переменной, до ее смерти, то тип ему будет ясен из контекста. Тем более, больших методов вообще лучше избегать.
Не стоит недооценивать прогресс. За какие-то 30 лет, компьютерные технологии продвинулись настолько, что мы уже на полном серьёзе начинаем задумываться о роботах. О настоящих роботах. Еще несколько лет назад их вообще не было, а теперь они уже сами ходят. Их пинают, а они не падают. Сбивают их с ног палками, а они снова встают. Уже сегодня пресловутый искусственный интеллект классифицирует наши личные фото в социальных сетях. А распознавание голоса? Я регулярно пользуюсь. Это уже повседневная жизнь. А вы говорите лично не коснется. Уже коснулось.
Ну вообще я говорил про фильтры, которые вкручиваются в кувшин. Эти через месяц становятся бесполезны практически.
Вот, ради интереса посчитал стоимость использования первого попавшегося осмосного фильтра. Может быть можно и существенно меньшими деньгами обойтись, просто некогда сейчас искать.
Аквафор DWM-101S Морион: 7900 р.
Плюс само устройство, раз в 10 лет хотя бы менять = 790 р/год
Оптимистичный расчет: 580+1120+1000+570+790=4060 р/год = 78 р/неделя
Пессимистичный рассчет: 1160+2240+1327+570+790=6087 р/год = 117 р/неделя
На всякий случай ссылка, откуда я брал информацию о ценах и сроках замены частей: http://www.aquaphor.ru/filters/dwm-101s
Это примерная цена 10 и 15 литров бутилированной воды соответственно. В неделю. На одного это мне за глаза хватит. Я больше пяти литров в неделю не трачу обычно. Учитывая, что большую часть времени я провожу на работе, и там пью чай/кофе. Готовки тоже немного. Так что, даже если уложиться во вдвое меньшие деньги за фильтр, это все равно будет не дешевле, чем мне обходится вода в бутылках. На семью наверное выгоднее выйдет. А одному — не особо. К тому же, что будет, если я в командировку на пару недель уеду? Не зацветет ли вода в фильтре? Еще надо учесть такой вариант, что начал воду набирать в фильтр, и вдруг потекла ржавая. Не испортится ли он от такого? С другой стороны, может при моем темпе использования, менять модули придется реже, чем написано в характеристиках. Короче много нюансов. Очень многое зависит от разных жизненных факторов. Например, если поблизости негде купить воды в бутылке, фильтр будет просто удобнее. Говоря поблизости, я говорю о двух-трех минутах ходьбы, все же вода не такая легкая, таскать ее. Очень существенно на выбор может повлиять наличие автомобиля. Ну и т.д.
Так что бутилированная все же получше. По крайней мере, когда водопроводная — откровенно плоха. При этом я беру самую дешевую воду. В том, что вода, которая вдвое дороже, будет в два раза лучше, я сильно сомневаюсь.
Да, вы правы. Сейчас погуглил и нашел статью, где человек пишет, что проблема на Raspberry Pi с графическим драйвером. Там даже ссылка на экспериментальный образ ОС есть. Будем пробовать. А вообще, на Raspberry Pi 2, сама идея с браузером сносно работает. Скорость работы, в целом, приемлемая. Только WebGL выдает один кадр в несколько секунд. Раньше, когда искал инфу по этому поводу, везде находил только, что аппаратного ускорения WebGL нет, и решил что это ограничение на уровне железа.
На всякий случай, может кому пригодится ссылка (хотя, на данный момент, она первая в гугле по запросу raspberry pi 2 webgl):
https://www.scirra.com/blog/ashley/23/how-to-get-webgl-on-the-raspberry-pi-2
Языки программирования добавляют функциональные примеси для того, чтобы сделать язык более универсальным и удобным. Это вполне логично с их стороны. По этой же причине во многих языках высокого уровня можно делать ассемблерные вставки. По этой же причине, в C# можно добавить unsafe код.
Если топор не подходит для того, чтобы копать землю, и человек берет с собой, и топор, и лопату, чтобы сначала срубить дерево, а потом выкопать пень, разве это говорит о слабости топора?
Вот уже получается, что ФП может найти свое применение, и на сервере и на клиенте, и в играх. И это не какие-то редкие случаи, не какой-то специфичный софт, а самые общие вещи: сервера, графический интерфейс, рендеринг, расчет физики.
Но будущее, на мой взгляд, за гибридным подходом. Сплав ООП и ФП, на мой взгляд, наиболее удобен с практической точки зрения.
Да и не картинами едиными. Сможет ли нейронная сеть сочинить музыкальную композицию, наравне с Моцартом или Вивальди? Или написать книгу не хуже, чем «Война и мир»? Наверное когда-нибудь сможет. Но это будет уже ИИ, не уступающий человеку. Что тогда будет с людьми, я лично не знаю. Одно знаю наверняка — это будет уже совсем другой мир. Надеюсь человеку в нем найдется место. Ну а если нет, это будет значить, что мы где-то свернули не туда.