Статья понравилась. Правда, автор увлекся насчет собственных хотелок, а концепт, он должен быть универсальным. Хорошо, что он этого осознает и сделал два варианта. Но все же, насчет оптимизации периферию можно еще поработать. :)
Я кстати, тоже любитель маленьких компьютеров. По сути, они у меня всегда в роли главного рабочего компьютера. Но занимаюсь я программирования а не администрации. Использовал и eeepc и всякие другие нетбуки. Сейчас использую ASUS X102BA на AMD A4-1200 (2x1GHz, 4GB RAM).
Для меня, очень важно, чтобы клавиатура была хорошая. И мне кажется, что если толщина компьютера будет 30мм, то и место под механической клавиатуры должно быть достаточно. Не полноценную, конечно, но хотя бы на cherry low profile: https://techcrunch.com/2018/01/12/cherrys-new-low-profile-switches-may-help-bring-mechanical-keyboards-to-more-laptops/
А кто спорит? Но если человек сознательно начинает писать суб-оптимальный код, то он его будет писать всегда. Те же запросы к БД можно и нужно оптимизировать. И скорость реально повышается в десятки раз. Я писал форум на ассемблере и SQLite. Все говорят что SQLite медленная. Но нет, оказывается что SQLite очень даже быстрая, просто готовит запросы правильно надо. И теперь у меня есть самый быстрый форум в мире, на "самой медленной" БД.
В 95% прикладных задач основной затык на I/O (ожидание выполнения запроса на СУБД, ответа какого нибудь http api, чтение/запись файлов и т.д.), а уж никак не там где вы пишете. Это важно на вычислительных задачах, сложных алгоритмах, в системном ПО.
Так это же религиозная мантра. Мой опыт говорит наоборот – если пишешь оптимальный код, то программы получаются быстрые. Если всегда думаешь "преждевременная оптимизация зло!", то получаются медленные монстры, которые только убить можно, но никак не исправить. :)
Вот статья, человек просто сделал код на 20000% (sic!) быстрее, просто думая о оптимальности кода, а не написанием оптимального код:
Нет, не думаю. Это преждевременная, сознательная пессимизация всего кода. А когда придет время оптимизировать (ведь, "преждевременно" не значит "никогда") такой код придется переписывать начисто.
Оптимизировать раньше срока, конечно плохо. Но надо писать optimization-friendly код.
А производительность??? Правильные данные случаются намного чаще, чем неправильные. А при этом подходе, код будет выполнятся медленней всего именно когда данные правильные.
То есть, вред конкретный и вещественный, а польза несколько виртуальная…
А зачем слушать, если текст имеется? Я читаю намного быстрее, чем слушаю. Для людей, которые не могут читать, да, там просто надо бутон "слушать" и возможность перемотки и ускоренное проигрывание. (Моя дочь так смотрит видео лекции – на скорость x4, потому что видео иначе очень медленно смотрится), правда для аудио не знаю пройдет ли номер. Пусть слушающие люди скажут.
Всегда стоит опубликовать расшифровку как нормальный текст сразу за аудио. Ведь многие предпочтут прочитать побыстрее текст, а не слышать медленно звук. И это не имеет к доступностью и болезней никакое отношение.
Кстати, некоторые дислектические проблемы иногда приходится решать и для вполне обычных людей. Вот у меня, программируя на ассемблере для x86 (важно что x86) появилась проблема неразличимости "ebx" от "edx" в ассемблерных текстах. Потому что ассемблер читается сверху вниз и так b и d выглядят одинаково.
ibakaidov А ваш сайт тоже не очень. На бутоны (которые появляются по наводке курсора) нельзя кликать, только на текст ссылки.
А пишу это не чтобы придраться, а чтобы иллюстрировать тот факт, что сделать сайт доступным, дело весьма непростое и даже неоднозначное. Вот вам например кликать только на текст показалось вполне доступным. А мне (у меня все в порядке с здоровья) показалось, что если бутон появляется при наведению, то можно кликать туда.
Может, конечно, кто-то на такое и способен, я же просто смирился с тем, что компиляторы оптимизируют лучше человека (да и я не видел, чтобы кто-то этот тезис оспаривал).
Я не только оспариваю, но и несколько раз проверял экспериментально. Получается парадоксальный результат — все верно – компилятор компилирует отлично, но все равно, программы на ассемблере получаются быстрее. Дело в том, что человек на ассемблере пишет не так как на ЯВУ (и в этом ошибаются все, которые сравнивают программирование на ассемблер и ЯВУ). Когда пишет на ассемблере, программист выбирает другие алгоритмы, другую архитектуру программы.
Потому что ленивый и выбирает то, что легче написать именно на ассемблере и то что легче будет поддерживаться. Та же самая программа, можно написать и на C/C++, только код будет смотреться совершенно дико и неестественно.
Я проверял все это несколько раз, и всегда результат одинаков. Можете попробовать сами. Надо только писать более менее реальную программу, а не "алгоритм XYZ".
Мне больше интересно, как сейчас дела обстоят (и обстоят ли) с программированием под FreeDOS или что-то подобное. Там ведь ассемблер вполне себе удобен (особенно для резидентных программ).
Работать под (Free)DOS не имеет никакого смысла, потому что просто нельзя использовать возможности компьютера. А вот в Linux программировать на ассемблере очень просто. Почти как в DOS.
Использование ассемблера в вычислительном коде скорее всего приведет к замедлению ваших программ.
А вы пробовали? Я да. Несколько раз. И дело в том, что нет, не получается. На ассемблере всегда получается намного быстрее.
На C/C++ можно написать быстрые программы, но дело в том, что надо ясно представлять как они должны выглядеть на ассемблере. А потом обмануть компилятора, чтобы сгенерировать нужный ассемблерский код. Для меня проще написать сразу на ассемблере. :P
Статья понравилась. Правда, автор увлекся насчет собственных хотелок, а концепт, он должен быть универсальным. Хорошо, что он этого осознает и сделал два варианта. Но все же, насчет оптимизации периферию можно еще поработать. :)
Я кстати, тоже любитель маленьких компьютеров. По сути, они у меня всегда в роли главного рабочего компьютера. Но занимаюсь я программирования а не администрации. Использовал и eeepc и всякие другие нетбуки. Сейчас использую ASUS X102BA на AMD A4-1200 (2x1GHz, 4GB RAM).
Для меня, очень важно, чтобы клавиатура была хорошая. И мне кажется, что если толщина компьютера будет 30мм, то и место под механической клавиатуры должно быть достаточно. Не полноценную, конечно, но хотя бы на cherry low profile: https://techcrunch.com/2018/01/12/cherrys-new-low-profile-switches-may-help-bring-mechanical-keyboards-to-more-laptops/
А даже и линка то не было. А вот, сайты SQLite и Fossil не упали. Это многое говорит насчет быстродействие Fossil.
Ну, ну, а разработчики например myBB, SMF или Flarum тоже так считают?
А кто спорит? Но если человек сознательно начинает писать суб-оптимальный код, то он его будет писать всегда. Те же запросы к БД можно и нужно оптимизировать. И скорость реально повышается в десятки раз. Я писал форум на ассемблере и SQLite. Все говорят что SQLite медленная. Но нет, оказывается что SQLite очень даже быстрая, просто готовит запросы правильно надо. И теперь у меня есть самый быстрый форум в мире, на "самой медленной" БД.
Так это же религиозная мантра. Мой опыт говорит наоборот – если пишешь оптимальный код, то программы получаются быстрые. Если всегда думаешь "преждевременная оптимизация зло!", то получаются медленные монстры, которые только убить можно, но никак не исправить. :)
Вот статья, человек просто сделал код на 20000% (sic!) быстрее, просто думая о оптимальности кода, а не написанием оптимального код:
https://medium.com/@okaleniuk/premature-optimization-is-the-root-of-all-evil-is-the-root-of-evil-a8ab8056c6b
Нет, не думаю. Это преждевременная, сознательная пессимизация всего кода. А когда придет время оптимизировать (ведь, "преждевременно" не значит "никогда") такой код придется переписывать начисто.
Оптимизировать раньше срока, конечно плохо. Но надо писать optimization-friendly код.
А производительность??? Правильные данные случаются намного чаще, чем неправильные. А при этом подходе, код будет выполнятся медленней всего именно когда данные правильные.
То есть, вред конкретный и вещественный, а польза несколько виртуальная…
А вуз, вуз какой?! У меня дочка поступать будет в следующем году!
Мне тоже интересно.
Кстати, кешируется:
А зачем слушать, если текст имеется? Я читаю намного быстрее, чем слушаю. Для людей, которые не могут читать, да, там просто надо бутон "слушать" и возможность перемотки и ускоренное проигрывание. (Моя дочь так смотрит видео лекции – на скорость x4, потому что видео иначе очень медленно смотрится), правда для аудио не знаю пройдет ли номер. Пусть слушающие люди скажут.
Всегда стоит опубликовать расшифровку как нормальный текст сразу за аудио. Ведь многие предпочтут прочитать побыстрее текст, а не слышать медленно звук. И это не имеет к доступностью и болезней никакое отношение.
Кстати, некоторые дислектические проблемы иногда приходится решать и для вполне обычных людей. Вот у меня, программируя на ассемблере для x86 (важно что x86) появилась проблема неразличимости "ebx" от "edx" в ассемблерных текстах. Потому что ассемблер читается сверху вниз и так b и d выглядят одинаково.
Вот обсуждение на: https://ux.stackexchange.com/questions/43439/how-to-make-font-that-clearly-distinct-b-and-d-without-sacrificing-legibilit
В конце, концов, сделал "b" как "в" и все получилось как надо. :)
ibakaidov А ваш сайт тоже не очень. На бутоны (которые появляются по наводке курсора) нельзя кликать, только на текст ссылки.
А пишу это не чтобы придраться, а чтобы иллюстрировать тот факт, что сделать сайт доступным, дело весьма непростое и даже неоднозначное. Вот вам например кликать только на текст показалось вполне доступным. А мне (у меня все в порядке с здоровья) показалось, что если бутон появляется при наведению, то можно кликать туда.
Я не только оспариваю, но и несколько раз проверял экспериментально. Получается парадоксальный результат — все верно – компилятор компилирует отлично, но все равно, программы на ассемблере получаются быстрее. Дело в том, что человек на ассемблере пишет не так как на ЯВУ (и в этом ошибаются все, которые сравнивают программирование на ассемблер и ЯВУ). Когда пишет на ассемблере, программист выбирает другие алгоритмы, другую архитектуру программы.
Потому что ленивый и выбирает то, что легче написать именно на ассемблере и то что легче будет поддерживаться. Та же самая программа, можно написать и на C/C++, только код будет смотреться совершенно дико и неестественно.
Я проверял все это несколько раз, и всегда результат одинаков. Можете попробовать сами. Надо только писать более менее реальную программу, а не "алгоритм XYZ".
Я читаю вот это: https://fresh.flatassembler.net/lscr/
А значит, на 100%, все равно не использовали. :P
Работать под (Free)DOS не имеет никакого смысла, потому что просто нельзя использовать возможности компьютера. А вот в Linux программировать на ассемблере очень просто. Почти как в DOS.
А кто же еще? В анабиозе.
А вы пробовали? Я да. Несколько раз. И дело в том, что нет, не получается. На ассемблере всегда получается намного быстрее.
На C/C++ можно написать быстрые программы, но дело в том, что надо ясно представлять как они должны выглядеть на ассемблере. А потом обмануть компилятора, чтобы сгенерировать нужный ассемблерский код. Для меня проще написать сразу на ассемблере. :P