Ну вот я написал про Mac Mini, вы успешно мой пример проигнорировали. Кажется, просто не влезает в ваше представление о мире.
Я довольно давно отказался от тауэров, лет десять назад. Собирал себе и системники небольшие, сейчас вот на ноутах сижу. Работаю, пишу программы, всё ок.
Тренды не надо подтверждать цифрами. Я тут никому ничего не доказываю, я просто размышляю. Кажется, этот навык уже утрачивает свою актуальность.
Ну, нет, так нет. Будут люди носить с собой лист ватмана, а также мышь и клавиатуру. Или возможны варианты. Я вот не думаю, что там надо будет прямо "разговаривать", скорее, время от времени произносить названия.
Почему тайваньцев и китайцев? Маломерные форм-факторы — это международные стандарты. Я видел мини-системники производства HP и Dell, не говоря уже об эппловских Mac mini.
Мне кажется, вы хватаетесь за отдельные исключения, совершенно игнорируя то, что я написал — тенденцию. Не надо вам в футурологи.
Смотрел лекцию Владимира Пирожкова — это дизайнер (конструктор?) автомобилей, долгое время проработавший за рубежом. Он говорил, что надо обращать внимание на тенденции, чтобы понять, каким будет будущее. Тенденции с компьютерами заключатся в том, что системные блоки стремительно сжимаются, в то время, как мониторы не менее стремительно растут в ширину и высоту, становясь при этом всё тоньше.
В недалёком будущем, скажем, через 10-15-20 лет легко представить, что компьютер будет похож ни лист ватмана формата А4 или А3. Мы будем его сворачивать, носить с собой, раскладывать на столе, работать.
Понятно, что в таком виде мышь клавиатура будут не очень адекватными средствами ввода. Скорее всего, у нас будут жесты и голос.
Я могу представить, как на таком компьютере смогут работать дизайнеры или музыканты. Даже, возможно, авторы текстов. Но программисты?
Не знаю, какими будут языки программирования будущего, но, кажется, что они будут именно визуальными. Я пытался подобрать удачные примеры визуальных языков и у меня получился список, похожий на тот, что в статье. Мой список был поменьше, потому что я не настолько в теме. Тем не менее, конечные автоматы, разнообразные деревья и ER-диаграммы у меня были.
Блок-схемы в этот список не попали: я никогда не считал их удобными или удачными.
Я заметил, что удачные языки по своей природе декларативны, и это довольно предсказуемо. Думаю, что новая форма компьютеров вынудит нас переходить на визуальные языки и программировать жестами и голосом. Скорее всего, визуальные языки будут именно декларативными. Но пока конкретных вариантов я не видел.
Тут два аспекта. Стандартно, для вывода можно было использовать прерывания 10h (BIOS) и 21h (DOS). Конечно, Turbo Vision не использовала эти прерывания, потому что они работали медленно.
Там был собственный метод вывода и, конечно, он работал через видеопамять. Но как он вызывался? Через пользовательское прерывание 60h (или 61h, я сейчас уже не помню). Пользовательские прерывания отдавались на откуп программистам, их можно было использовать, как угодно. В Turbo Vision — для вывода.
Почему этот метод работал быстрее, чем прерывания BIOS? Там были режимы "скопировать прямоугольную область на экран", "повторить символ N раз" (это для повторения символов). В BIOS и DOS привязаны к курсору: чтобы вывести символ, надо передвинуть курсор. Это было медленно. Простое копирование в видеопамять без привязки к курсору — быстро.
Некоторые детали могут не соответствовать действительности. История из 92-го года, больше 30-ти лет прошло.
Я не знаю, что такое Graphics Vision. Тогда у ребят в Turbo Pascal, кажется, 6-й версии была текстовая GUI библиотека Turbo Vision. Оказалось, что весь её вывод сконцентрирован буквально в одном пользовательском прерывании, если не ошибаюсь, 60h.
Мы переводили экран в графический режим при старте, перехватывали прерывание и там был код, который выводил текст в графических режимах 80060016 или 64040016. Думаю, мы не одни такие были, так что наверное были и другие похожие решения.
В начале 90-х принимал участие в переводе Turbo Vision в графический режим для новых тогда адаптеров SVGA. Вдоль и поперёк перечитывал книги Джордейна и Нортона, которые рассказывали, как управлять адаптерами EGA. Естественно, делал на языке ассемблера.
Это не так круто, как эффект Фехнера (я про него и не знал до прочтения статьи), но где-то рядом. Испытал острое чувство ностальгии. Спасибо.
Здесь есть проблема в коде. В .NET double.Epsilon — это не то же самое, что DBL_EPSILON из стандартной библиотеки C. Давняя проблема, которая тянется с момента появления .NET.
В C/C++ под эпсилоном понимают максимальную возможную точность. Формальное определение: это такое минимальное число, при котором выполняется неравенство DBL_EPSILON + 1.0 != 1.0. Используется для сравнения чисел друг с другом, при этом числа не должны быть равны нулю, иначе смысл сравнения теряется.
Если хотите сравнивать с нулём, нужно использовать значение DBL_MIN — это минимальное представимое нормализованное число. Отсекает все ненормализованные числа, приравнивая их к нулю.
В .NET значение double.Epslion — совершенно бесполезное в принципе представимое минимальное число. Оно даже ненормализованное, то есть там значимых бит меньше, чем 52.
Его нельзя использовать ни для чего, в том числе для определения слишком маленьких чисел, потому что чисел меньше не бывает. Оно на 300 порядков меньше, чем DBL_EPSILON. В C/C++ ему соответствует константа DBL_TRUE_MIN.
Самый простой способ поправить код: использовать double.MinValue вместо dboule.Epslion там, где сравниваете с 0, и использовать double.BitIncrement вместо DBL_EPSILON. Это аналог, который появился, если не ошибаюсь, в 6-м .NET Core. Значения констант, чтобы не искать, можно посмотреть в MSDN.
Яндекс Школа оплачивает проезд и проживание тем, кто прошёл отборочные. У Т1 не знаю точно, как всё устроено, но это кемпинг, то есть все живут где-то в живописном месте за городом. И у Яндекса, и у Т1 есть офисы в разных городах Москвы и есть возможность удалённой работы.
Я сам давным-давно сеньор, у меня, наверное, даже не пик карьеры, а закат. Проблем с поиском работы нет очень давно. Но мне не очень нравится, что толковым студентам трудно найти работу, потому что в индустрии все боятся людей, прошедших двухмесячные курсы.
Мой совет — искать стажировки, которые проходят крупные компании. Вот Яндекс.Школа в этом году летом работает, есть шанс хорошо провести время и попасть на работу в Яндекс. Плюс Т1 собирается проводить летний кэмп и тоже с возможностью потом устроится на работу.
Это как бы ещё один совет к тем, что к статье, надеюсь, что всё-таки полезный, а не вредный.
Да, вы совершенно правы, это моя ошибка. Я просто метался в этом месте, сначала написал тысячу, потому подумал, что это выбивается из примера с вопросами. Никто же не будет задавать тысячу вопросов.
Поменял на двадцать, забыл убрать тысячу. Решил убрать тысячу, убрал двадцать. Всё потому, что середина рабочего дня, тем более понедельника. Созвоны, программирование, опять созвоны, опять программирование, и где-то в перерывах исправление ошибок.
Очень здорово, что где-то хорошая документация есть. Да она, очевидно есть. Пусть MSDN это проект коммерческой компании, там люди за зарплату пишут. Но ведь и во многих open source проектах с документацией все в порядке.
Просто почему то в разнообразных легаси проектах с документацией всё плохо.
Ну вот я написал про Mac Mini, вы успешно мой пример проигнорировали. Кажется, просто не влезает в ваше представление о мире.
Я довольно давно отказался от тауэров, лет десять назад. Собирал себе и системники небольшие, сейчас вот на ноутах сижу. Работаю, пишу программы, всё ок.
Тренды не надо подтверждать цифрами. Я тут никому ничего не доказываю, я просто размышляю. Кажется, этот навык уже утрачивает свою актуальность.
Нет, я просто размышляю. Для программиста это нормально — разминать мозги и думать на всякие интересные темы. Но, видимо, не для всякого программиста.
Похоже, есть и те, кому думать и фантазию включать неинтересно. Или нечем.
Ну, я не знаю. Уже лет двадцать, как ноуты повсеместно используются. Не слышали?
Ну, нет, так нет. Будут люди носить с собой лист ватмана, а также мышь и клавиатуру. Или возможны варианты. Я вот не думаю, что там надо будет прямо "разговаривать", скорее, время от времени произносить названия.
Почему тайваньцев и китайцев? Маломерные форм-факторы — это международные стандарты. Я видел мини-системники производства HP и Dell, не говоря уже об эппловских Mac mini.
Мне кажется, вы хватаетесь за отдельные исключения, совершенно игнорируя то, что я написал — тенденцию. Не надо вам в футурологи.
Смотрел лекцию Владимира Пирожкова — это дизайнер (конструктор?) автомобилей, долгое время проработавший за рубежом. Он говорил, что надо обращать внимание на тенденции, чтобы понять, каким будет будущее. Тенденции с компьютерами заключатся в том, что системные блоки стремительно сжимаются, в то время, как мониторы не менее стремительно растут в ширину и высоту, становясь при этом всё тоньше.
В недалёком будущем, скажем, через 10-15-20 лет легко представить, что компьютер будет похож ни лист ватмана формата А4 или А3. Мы будем его сворачивать, носить с собой, раскладывать на столе, работать.
Понятно, что в таком виде мышь клавиатура будут не очень адекватными средствами ввода. Скорее всего, у нас будут жесты и голос.
Я могу представить, как на таком компьютере смогут работать дизайнеры или музыканты. Даже, возможно, авторы текстов. Но программисты?
Не знаю, какими будут языки программирования будущего, но, кажется, что они будут именно визуальными. Я пытался подобрать удачные примеры визуальных языков и у меня получился список, похожий на тот, что в статье. Мой список был поменьше, потому что я не настолько в теме. Тем не менее, конечные автоматы, разнообразные деревья и ER-диаграммы у меня были.
Блок-схемы в этот список не попали: я никогда не считал их удобными или удачными.
Я заметил, что удачные языки по своей природе декларативны, и это довольно предсказуемо. Думаю, что новая форма компьютеров вынудит нас переходить на визуальные языки и программировать жестами и голосом. Скорее всего, визуальные языки будут именно декларативными. Но пока конкретных вариантов я не видел.
Было и такое в моей жизни. Жив, здоров, и всё ещё не подвержен паранойе.
И, более, того, всё ещё убеждён, что инженер имеет право на ошибки. А паранойя это плохо, говорят даже, что это болезнь.
Так что лучше быть здоровым и богатым, чем нездоровым и с постоянными мыслями о пропадающих деньгах.
Сразу какие-то ужасы... Ну, упал и упал. Даже у гугла прод падает.
И всё-таки паранойя — это грустно. В пику паранойе предлагаю практиковать разумный пофигизм. Сделал ошибку — и фиг с ней!
Иначе можно погрязнуть в чтении бесполезных блогов.
Согласен, что странно, но в паскалевской версии TV было так, и это сильно упростило нам разработку графического расширения.
Тут два аспекта. Стандартно, для вывода можно было использовать прерывания 10h (BIOS) и 21h (DOS). Конечно, Turbo Vision не использовала эти прерывания, потому что они работали медленно.
Там был собственный метод вывода и, конечно, он работал через видеопамять. Но как он вызывался? Через пользовательское прерывание 60h (или 61h, я сейчас уже не помню). Пользовательские прерывания отдавались на откуп программистам, их можно было использовать, как угодно. В Turbo Vision — для вывода.
Почему этот метод работал быстрее, чем прерывания BIOS? Там были режимы "скопировать прямоугольную область на экран", "повторить символ N раз" (это для повторения символов). В BIOS и DOS привязаны к курсору: чтобы вывести символ, надо передвинуть курсор. Это было медленно. Простое копирование в видеопамять без привязки к курсору — быстро.
Некоторые детали могут не соответствовать действительности. История из 92-го года, больше 30-ти лет прошло.
Я не знаю, что такое Graphics Vision. Тогда у ребят в Turbo Pascal, кажется, 6-й версии была текстовая GUI библиотека Turbo Vision. Оказалось, что весь её вывод сконцентрирован буквально в одном пользовательском прерывании, если не ошибаюсь, 60h.
Мы переводили экран в графический режим при старте, перехватывали прерывание и там был код, который выводил текст в графических режимах 80060016 или 64040016. Думаю, мы не одни такие были, так что наверное были и другие похожие решения.
В начале 90-х принимал участие в переводе Turbo Vision в графический режим для новых тогда адаптеров SVGA. Вдоль и поперёк перечитывал книги Джордейна и Нортона, которые рассказывали, как управлять адаптерами EGA. Естественно, делал на языке ассемблера.
Это не так круто, как эффект Фехнера (я про него и не знал до прочтения статьи), но где-то рядом. Испытал острое чувство ностальгии. Спасибо.
Выздоравливайте!
Здесь есть проблема в коде. В .NET
double.Epsilon— это не то же самое, чтоDBL_EPSILONиз стандартной библиотеки C. Давняя проблема, которая тянется с момента появления .NET.В C/C++ под эпсилоном понимают максимальную возможную точность. Формальное определение: это такое минимальное число, при котором выполняется неравенство
DBL_EPSILON + 1.0 != 1.0.Используется для сравнения чисел друг с другом, при этом числа не должны быть равны нулю, иначе смысл сравнения теряется.
Если хотите сравнивать с нулём, нужно использовать значение
DBL_MIN— это минимальное представимое нормализованное число. Отсекает все ненормализованные числа, приравнивая их к нулю.В .NET значение
double.Epslion— совершенно бесполезное в принципе представимое минимальное число. Оно даже ненормализованное, то есть там значимых бит меньше, чем 52.Его нельзя использовать ни для чего, в том числе для определения слишком маленьких чисел, потому что чисел меньше не бывает. Оно на 300 порядков меньше, чем
DBL_EPSILON. В C/C++ ему соответствует константаDBL_TRUE_MIN.Самый простой способ поправить код: использовать
double.MinValueвместоdboule.Epslionтам, где сравниваете с 0, и использоватьdouble.BitIncrementвместоDBL_EPSILON. Это аналог, который появился, если не ошибаюсь, в 6-м .NET Core. Значения констант, чтобы не искать, можно посмотреть в MSDN.Думаю, тут всё просто. На стажировках джуны, они по определению не могут знать бизнес-логику. Учите алгоритмы.
Яндекс Школа оплачивает проезд и проживание тем, кто прошёл отборочные. У Т1 не знаю точно, как всё устроено, но это кемпинг, то есть все живут где-то в живописном месте за городом. И у Яндекса, и у Т1 есть офисы в разных городах Москвы и есть возможность удалённой работы.
Я сам давным-давно сеньор, у меня, наверное, даже не пик карьеры, а закат. Проблем с поиском работы нет очень давно. Но мне не очень нравится, что толковым студентам трудно найти работу, потому что в индустрии все боятся людей, прошедших двухмесячные курсы.
Мой совет — искать стажировки, которые проходят крупные компании. Вот Яндекс.Школа в этом году летом работает, есть шанс хорошо провести время и попасть на работу в Яндекс. Плюс Т1 собирается проводить летний кэмп и тоже с возможностью потом устроится на работу.
Это как бы ещё один совет к тем, что к статье, надеюсь, что всё-таки полезный, а не вредный.
Да, вы совершенно правы, это моя ошибка. Я просто метался в этом месте, сначала написал тысячу, потому подумал, что это выбивается из примера с вопросами. Никто же не будет задавать тысячу вопросов.
Поменял на двадцать, забыл убрать тысячу. Решил убрать тысячу, убрал двадцать. Всё потому, что середина рабочего дня, тем более понедельника. Созвоны, программирование, опять созвоны, опять программирование, и где-то в перерывах исправление ошибок.
Спасибо. Всё исправил, теперь там двадцать
Очень здорово, что где-то хорошая документация есть. Да она, очевидно есть. Пусть MSDN это проект коммерческой компании, там люди за зарплату пишут. Но ведь и во многих open source проектах с документацией все в порядке.
Просто почему то в разнообразных легаси проектах с документацией всё плохо.
Я совершенно согласен. Правда, по какой-то причине я ни разу не видел технического писателя ни в одной из команд, где я работал.