Pull to refresh
65

Programmer

1,5
Rating
105
Subscribers
Send message

Отличная статья! И еще был бы интересен непосредственно обзор языка Erlang.

Я скорее о самих технологиях разработки. Вот все эти огромные скрипты производят впечатление чего-то неправильного. Сам способ превращения веб-приложения в андроид-приложение - тоже. Чисто с эстетической точки зрения.

Вы уверены что это "для самых маленьких"? Не знаю, не знаю... но раньше, чтобы написать программу для большинства ОС, достаточно было просто поставить соответствующую среду разработки (или просто компилятор) и написать программу. Начиная с простейшего консольного hello.c под любые ОС. Под винду тоже все было просто - winapi, Delphi/Builder, MFC, WinForms, Qt, в общем практически любой фреймворк предполагал просто запуск своей среды разработки и выбор там шаблона простейшего приложения. С Android я почти не имел дела, но когда разбирался - пришел к интересным выводам: с одной стороны разработчики Android Studio попытались сделать по-человечески. Но с другой хвосты gradle и прочего скриптожопства торчат изо всех щелей, что приводит порой к странным эффектам, и даже к странным пунктам меню вроде "Sync project with gradle files", "Invalidate caches", "Reload all from disk" и даже "Repair IDE".

И в целом, глядя на вот это всё, начинаешь понимаешь, зачем современным системам и программам десятки гигабайт оперативки.

Приятно смотреть на старые интерфейсы - и аппаратные, и программные (и вряд ли тут можно списать на ностальгию - подобных устройств у меня никогда не было). Но если оно работало на 32МБ, то возникает вопрос - что же за шлак крутится в современных ОС, которым подавай 32ГБ?

Кстати, а встроенная функция шифрования виртуальных машин в VirtualBox и VMWare тоже сюда относится?

Классные устройства. Если бы я ездил на работу на транспорте, то обязательно приобрел бы какое-нибудь.

Вообще, когда-то давно я обратил внимание на устройство Samsung Q1 Ultra - там клавиатура была по бокам от экрана, что выглядит весьма удобно для того чтобы набирать текст пальцами обеих рук, одновременно удерживая устройство. У представленного в обзоре GPD Win 4 клавиатура снизу, что наверное менее удобно (хотя может я и ошибаюсь - не попробуешь не поймешь). Но кажется, здесь нужно удерживать устройство одной рукой за боковую часть, а второй набирать текст.

Еще было бы неплохо, если бы в GPD обратили внимание на e-lnk и mirasol экраны (если первая технология активно используется в читалках, то вторая как-то не пошла, хотя было одно устройство Kyobo). Иногда низкое энергопотребление и возможность работать при ярком солнечном освещении важнее чем полноценная цветопередача.

Как-то раз (лет 5 назад?) мне потребовалось запостить фотку в Инстаграм (обычно я этим не занимаюсь, а тогда вот понадобилось). И я кажется какой-то браузер переключал в режим отладки, оттуда в режим имитации мобильного браузера, и уже оттуда отправлял фотку. А из обычного десктопного было не отправить.

Новые поколения легко воспринимают такие новшества) Для них это уже сейчас естественно, и в будущем будет еще более естественно. Возможно мышление как-то специально подстроится под общение с такими помощниками, или возникнут еще какие-то интересные эффекты.

А некоторые из нас так и останутся "бабками, не признающими электричества")) Я один из таких. Во-первых, не люблю разговаривать голосом. Мне проще набрать текст и щелкнуть мышью. Во-вторых, не оставляет мысль, что настоящее имя всех этих помощников - "товарищ майор". Если до этого еще не додумались, то очень странно.

Threads? Захожу на сайт https://www.threads.net/, а там qr-код "скачать приложение" (для iOS и Android) и всё. Они что, пользователей нормальных компьютеров уже за людей не считают?

Ну раньше на Сях кодили, а теперь на каких-то JS-фреймворках:) Результат закономерен. Впрочем, было бы интересно сравнить свободное ПО - тот же Linux - на старом железе и на новом. У меня было ощущение, что у линукса GUI помедленнее чем у видны. И раньше и сейчас.

Да. Но это противоречит модному в наши дни веянию сильной типизации.

Зато не противоречит модному в наши дни веянию автоматического вывода типов :)

Совершенно верно. Поэтому фундаментальные математические константы должны быть нетипизированными и представлять соответствующие числа (Пи, Е и т.д.) как математические абстракции, а не как литералы конкретного типа. А это можно сделать только путем введения ключевых слов языка (возможно контекстных, видимых лишь в каком-то пространстве имен, не важно).

То есть, допустим, есть у нас "длинная арифметика" типа GMP - ОК, константа Pi и там будет константой той длины, которая используется в данный момент. Хоть килобайтной длины:)

Причем эту концепцию можно распространить и на все остальные литералы. Допустим, число 42: что это - int32, int64, uint8, float, double? Может вообще какой нибудь экзотический fixed point формат? Это должен решать компилятор с помощью автовывода типа. У литерала нет специальных суффиксов типа, но в большинстве существующих языков тип все равно прибит к литералу.

Аналогично, строковый литерал может быть однобайтовым (в одной из множества кодировок), utf8, utf16. utf32 и т.д. Конкретный тип пусть выводит компилятор.

Если мы хотим сделать литерал конкретного типа - используем явные суффиксы, конструкторы или приведение типов. В большинстве же случаев тип можно извлечь из контекста и опций компиляции.

Я задумывался о том, как лучше в языке программирования реализовать фундаментальные математические константы, так чтобы пользоваться ими было и быстро, и удобно, и интуитивно понятно. Предлагаемый вариант со знаками вопроса имеет проблему: в ASCII (а именно это множество берется за основу для алфавита языков) доступных спецсимволов всего 32, и они крайне дефицитны (отсюда и всевозможные составные операторы, и несколько функций у одного оператора в зависимости от контекста). В общем, жалко. Знак вопроса гораздо лучше подходит для реализации нуллабельности и опционалов.

В С/С++ математические константы определены в math.h (что конечно не совсем хорошо, учитывая, что во многих процессорах есть встроенные константы). И даже если использовать math.h - еще есть некий костыль в виде _USE_MATH_DEFINES, который тоже нужно писать каждый раз.

Хорошо бы сделать их просто ключевыми словами языка. И если с Pi это еще прокатит, то вот число E... ну нехорошо делать одну букву ключевым словом. Чисто эстетически нехорошо.

Использовать префиксы как в С++ (M_PI, M_2PI, M_E)? Вариант, но выглядит кривовато, не слишком эстетично.

Использовать пространства имен (Math.Pi, Math.E)? Тоже вариант, но по идее в том же Math должны содержаться и всякие синусы с косинусами; и если в некотором файле открыть это пространство имен (не писать же каждый раз Math.sin(x) и Math.cos(x)), то опять же однобуквенные имена типа E окажутся в области видимости.

В Go самый правильный (с моей точки зрения разумеется) синтаксис функций

  • начинаются с ключевого слова (кажется после С++ уже все поняли что так лучше)

  • ничего лишнего (двоеточия, стрелочки и прочий мусор)

  • обычные функции и лямбды имеют единый синтаксис (опять же никакой стремной экзотики с палками и стрелками); таким образом нет необходимости выделять лямбды в отдельную концепцию, это просто функции

Обожаю такие истории:) Вообще хорошо быть подростком, когда энергия прет через край, когда всё интересно, когда ты мог быть "в потоке" хоть часами напролет каждый день, и кодить, кодить, кодить...

Это все какая-то жуткая привязка к возможностям современного человечества и человеческим представлениям о мире. Как в эпоху космонавтики газеты наводнили всякие истории про пришельцев и НЛО, так и здесь - появились достаточно мощные компьютеры, и вот кому-то приходит в голову мысль "а не симуляция ли мы".

Нет, мы разумеется не симуляция в таком примитивном смысле этого слова. Но думаю, на фундаментальном уровне, физическая реальность имеет тесную связь с математикой и информатикой, то есть где-то там, на очень глубоком уровне понимания природы, нет принципиальной разницы между "реальностью" и "симуляцией". Задумайтесь например, что обеспечивает одинаковость масс покоя и зарядов всех электронов во Вселенной? Или постоянство скорости света? Есть некие правила, по которым Вселенная работает. И эти правила, сам факт их наличия, говорит о многом. Это верный признак наличия достаточно компактной информационной структуры, лежащей в основе всей этой немыслимо огромной Вселенной. При желании, это можно рассматривать как признак "симуляции", но разумеется не в примитивно-человеческом смысле этого слова.

А современные браузеры вообще поддерживают тег object и встраивание com-объектов в веб-страницы? Или это давно и окончательно выпилили?

Просто эта фишка в принципе могла бы быть полезна для локальных применений. Например у меня видеоархив, в котором есть какие-то древние форматы типа flv, и есть идея написать что-то вроде локального веб-приложения для каталогизации и просмотра всего этого. Официальный тег video их точно не поймет (что с моей точки зрения странно - ИМХО, должно проигрываться всё, для чего в системе установлены кодеки... но разаботчики стандарта решили иначе).

Я примерно так и сделал, скачал некую подборку maven offline, сделал как у них по инструкции. Но увы, все равно кто-то лезет в инет. Причем особенность там в том, что инет (там где я хочу все это поставить) есть, но специфический - пропускает запросы только с определенным user-agent. Я и с подменой заголовков играл - натыкаюсь на другие особенности, уже с https сертификатами и их подменой, версиями tls и прочим.

В общем, я к тому, что современный мир слишком завязан на инет. Исчезли те времена, когда можно было купить (или скачать) cd/dvd с полной оффлайн версией продукта (в том числе среды разработки) и спокойно пользоваться несколько лет, до выхода следующей верси. И это плохо еще тем, что вот такое самопроизвольно-непрерывное обновление всего и вся потенциально может что-то сломать в проекте. Программисты пакетов - тоже люди, и им тоже свойственно ошибаться.

Information

Rating
1,842-nd
Registered
Activity