Это не совсем так, например, для Nvidia 3D Vision такая развёртка как раз нужна. Правда, не каждый монитор, в котором есть частота 120 Гц, годится для Nvidia 3D Vision.
Я сам от хэш-таблиц ничего не хочу. Меня спросили, где массивы нужны — я и привёл доступный и очевидный для всех пример. Естественно, в силу распространённости этой структуры данных работу по укрощению массивов для неё конкретно уже кто-то провёл (причём, в функциональной версии от них решили отказаться). Но этим примером же всё применение массивов не ограничивается.
Так раз там IO или ST, то это уже не чисто функциональный код. Это «олдскульно-изменяемые массивы», и «непонятно, зачем писать на Хаскеле, если [они] нужны».
Есть, как раз с теми проблемами, что я и описал: чисто функциональная версия строится не на массивах, а на деревьях. Я не обязательно имел в виду хэш-таблицы. Просто это хороший пример, потому что это то, что всем знакомо, когда требуется запись в случайную ячейку массива, а не подряд. А так-то массив — это настолько базовая структура данных, что такие случаи — это вовсе не что-то из ряда вон выходящее.
Там, где хэш-таблицы нужны, например. Они реализованы на основе массивов, а в Haskell придётся их реализовывать деревьями, так что некоторые потери будут.
Взять-то да, а если нужно записывать? В случае неизменяемых массивов нужно их пересоздавать, и тогда уже неизвестно, насколько оптимальный код выдаст компилятор. А изменяемые массивы — это не чисто функциональные структуры, да и работать с ними неудобно в Haskell. Причём, настолько неудобно, что кто-то даже придумал препроцессор, чтобы это делать.
Речь-то не столько об алгоритмах, сколько о структурах данных. Приблизиться к сложности обычных структур можно с чисто функциональными, но достичь нет. Я, кстати, как раз только что нашёл книгу, в которой автор об этом пишет.
А ещё я не знаю, учитываются ли операции по записи в память, когда проводится весь этот анализ. Компилятор тут что-то оптимизирует, но шут его знает, насколько GHC хорошо с этим справляется, и вообще до какого предела всё оптимизируется с теоретической точки зрения.
Всё равно нужны же структуры данных, в которых доступ к любому элементу делается за постоянное время, а не линейное, как при чтении, так и при записи. С таким подходом, что если они требуются, то и писать на Haskell не стоит, ничего удивительного, что люди будут предпочитать более универсальные языки.
Когда я читал про Haskell, мне всё время не хватало нормальной информации по массивам. Везде описываются списки, но совершенно очевидно, что во многих случаях массивам они не замена. Из вышеперечисленных книг я только в Parallel and Concurrent Programming in Haskell нашёл упоминание Repa, но она какая-то уж больно специфическая. А массивов в Haskell уже придумали бог знает сколько, и новичку вовсе не очевидно, какой из них использовать. Это далеко не Java, где есть только массивы и ArrayList, выбор между которыми гораздо проще.
А ещё не хватает объяснения вот таких простых вещей, как выход из вложенного цикла, например. Это можно делать, конечно, и с помощью нескольких функций, но получится уже не так элегантно. А ситуация довольно банальная.
Проголосую, наверное, за Beginning Haskell. Там вроде бы неплохой обзор возможностей языка. Кроме того, там, я вижу, затрагиваются расширения GHC, без которых, как я постепенно выяснил к своему сожалению, никто ничего серьёзного не пишет, хотя в стандарт они не включены.
При чём тут вообще уникальный интерфейс? Основная идея Bootstrap — это построение сайтов, которые одинаково хорошо функционируют как на мобильных устройствах, так и на компьютерах. Bootstrap даёт в руки все необходимые инструменты для этого, а уж как они используются — это дело верстальщика.
Можно, разумеется, пользоваться только встроенными компонентами и никак не менять их внешний вид. Тогда да, с уникальностью будут проблемы. Но никто не мешает настроить внешний вид под себя или сделать свои. Смотря на сайты, сделанные с помощью Bootstrap, как-то не похоже, чтобы у них с уникальностью интерфейса были какие-то проблемы.
Это верно, но тут всё не так просто. В случае создания нового кода ты сам, разумеется, выбираешь, какие возможности использовать, а какие нет. Но если начинаешь работать с кодом других людей, которые себя искусственно не ограничивают в возможностях языка, то волей-неволей приходится вникать в них все сразу. И чем больше их в языке, тем сложнее программисту.
В частности поэтому я ещё, например, немного скептически отношусь и к утверждению, что нововведения в C++ облегчают работу с кодом. Да, написание нового кода-то упрощается, но старый код никуда не делся, и возможности, которые уже не нужно использовать в новом коде, всё равно нужно знать и понимать. Поэтому необходимый объём знаний только увеличивается.
С популярностью металла график вообще, по-моему, сильно напортачил. Например, взять Thrash Metal. Известно, что жанр возник в начале 80-х, дальше рос в популярности, и в начале 90-х она внезапно упала. Так продолжалось до 2000-х, когда жанр начал опять подниматься в популярности. График же показывает, что популярен жанр был только в начале 80-х в момент зарождения и немного в самом конце 80-х, а после этого якобы никто больше этот жанр не слушает.
Я ещё могу понять, почему там может не быть данных из XXI века: многие считают настоящими работами жанра именно те, которые появились в 80-е (хотя лично я, правда, с ними не очень согласен). Но почему середина 80-х там проваливается, хотя cамая классика жанра выходила именно в это время, я понять не могу. Я сначала подумал, что какие-то известные альбомы просто не добавили. У меня вот не отображается Metallica — Master Of Puppets. Но вроде альбомы Anthrax, Megadeth, Slayer, Testament и других известных групп там на месте, так что всё это не очень понятно.
Ну и с делением по жанрам там тоже действительно странно в некоторых местах. Почему-то Scorpions вдруг оказались в поджанре Hair Metal. Black и Death Metal зачем-то объединили, хотя это два разных поджанра, довольно сильно стилистически отличающихся друг от друга.
Не знаю, конечно, как у них с другими жанрами обстоит, поскольку я в них так хорошо не разбираюсь, но если всё так же, как и с металлом, то я совершенно согласен, что ценность этого сервиса довольно сомнительная.
А что им туда ещё поставить? Аппараты на новых чипах Qualcomm вряд ли стоит ждать раньше второго квартала, а этот уже будет в первом. Характеристики пока что вполне актуальные.
Я надеюсь, что они и дальше продолжат так делать. Я большой поклонник Sony (и Sony Ericsson, пока они не сменили название), сейчас у меня Z1, но должен сказать, что 5" — это мой предел. Если они начнут выпускать флагманы с большими размерами экрана, мне придётся покупать что-то другое. Так что тенденция однозначно радует.
Для стартовой цены совершенно нормально, она в первые недели наверняка быстро упадёт до вменяемых чисел. Кроме того, такая цена будет, скорее всего, в таких сетях, как Связной или Евросеть, а знающие люди смогут купить белый телефон и подешевле. Так что всё нормально.
Я, пожалуй, для начала скажу, что статью стоит больше воспринимать как эксперимент. Я никого не агитирую пересаживаться на NetBeans, просто решил поделиться тем, чем пользуюсь сам.
Вообще, когда я начинал программировать под Android, никакого Android Studio не было и в помине, равно как и IntelliJ Community Edition. Был только Eclipse, который лично меня сильно не радует. Я начал понемного экспериментировать с тем, как можно добавить поддержку разработки под Android в NetBeans, и в итоге пришёл к тому, что описано в этой статье.
Почему я не перешёл на Android Studio? Есть несколько причин: там нельзя работать с NDK, он ещё находится в разработке, и мне лично менее приятен в нём интерфейс. В основном из-за того, что там мелкие иконки и шрифты, а если их увеличить, то всё масштабируется довольно коряво, так что проводить там время мне менее приятно.
А резона пересаживаться, на самом деле, у меня особо нет, потому что после второй статьи получится почти то же, что и там. Чего не будет — это перехода на нужный ресурс из кода и, разумеется, графического редактора интерфейса. Ради этого я держу установленным Eclipse и запускаю, когда требуются услуги ADT.
Основной продукт компании — это всё же именно ПО, а под Micro они имели в виду, что пишут ПО для персональных компьютеров. Конечно, они занимаются не только этим, но оригинальное название, по-моему, вполне отражает их сильные стороны и на сегодняшний день.
А ещё я не знаю, учитываются ли операции по записи в память, когда проводится весь этот анализ. Компилятор тут что-то оптимизирует, но шут его знает, насколько GHC хорошо с этим справляется, и вообще до какого предела всё оптимизируется с теоретической точки зрения.
А ещё не хватает объяснения вот таких простых вещей, как выход из вложенного цикла, например. Это можно делать, конечно, и с помощью нескольких функций, но получится уже не так элегантно. А ситуация довольно банальная.
Проголосую, наверное, за Beginning Haskell. Там вроде бы неплохой обзор возможностей языка. Кроме того, там, я вижу, затрагиваются расширения GHC, без которых, как я постепенно выяснил к своему сожалению, никто ничего серьёзного не пишет, хотя в стандарт они не включены.
Сайт Grunt — это просто лендинг-страница? Или сайт Sentry? Или вот этот инструмент? Вот ещё одна коллекция сайтов, сделанных на Bootstrap. По-моему, очевидно, что на Bootstrap можно делать не только лендинг-страницы.
Да, кто-то сделал кривой сайт. При чём тут сам Bootstrap?
Можно, разумеется, пользоваться только встроенными компонентами и никак не менять их внешний вид. Тогда да, с уникальностью будут проблемы. Но никто не мешает настроить внешний вид под себя или сделать свои. Смотря на сайты, сделанные с помощью Bootstrap, как-то не похоже, чтобы у них с уникальностью интерфейса были какие-то проблемы.
В частности поэтому я ещё, например, немного скептически отношусь и к утверждению, что нововведения в C++ облегчают работу с кодом. Да, написание нового кода-то упрощается, но старый код никуда не делся, и возможности, которые уже не нужно использовать в новом коде, всё равно нужно знать и понимать. Поэтому необходимый объём знаний только увеличивается.
Я ещё могу понять, почему там может не быть данных из XXI века: многие считают настоящими работами жанра именно те, которые появились в 80-е (хотя лично я, правда, с ними не очень согласен). Но почему середина 80-х там проваливается, хотя cамая классика жанра выходила именно в это время, я понять не могу. Я сначала подумал, что какие-то известные альбомы просто не добавили. У меня вот не отображается Metallica — Master Of Puppets. Но вроде альбомы Anthrax, Megadeth, Slayer, Testament и других известных групп там на месте, так что всё это не очень понятно.
Ну и с делением по жанрам там тоже действительно странно в некоторых местах. Почему-то Scorpions вдруг оказались в поджанре Hair Metal. Black и Death Metal зачем-то объединили, хотя это два разных поджанра, довольно сильно стилистически отличающихся друг от друга.
Не знаю, конечно, как у них с другими жанрами обстоит, поскольку я в них так хорошо не разбираюсь, но если всё так же, как и с металлом, то я совершенно согласен, что ценность этого сервиса довольно сомнительная.
Вообще, когда я начинал программировать под Android, никакого Android Studio не было и в помине, равно как и IntelliJ Community Edition. Был только Eclipse, который лично меня сильно не радует. Я начал понемного экспериментировать с тем, как можно добавить поддержку разработки под Android в NetBeans, и в итоге пришёл к тому, что описано в этой статье.
Почему я не перешёл на Android Studio? Есть несколько причин: там нельзя работать с NDK, он ещё находится в разработке, и мне лично менее приятен в нём интерфейс. В основном из-за того, что там мелкие иконки и шрифты, а если их увеличить, то всё масштабируется довольно коряво, так что проводить там время мне менее приятно.
А резона пересаживаться, на самом деле, у меня особо нет, потому что после второй статьи получится почти то же, что и там. Чего не будет — это перехода на нужный ресурс из кода и, разумеется, графического редактора интерфейса. Ради этого я держу установленным Eclipse и запускаю, когда требуются услуги ADT.