Обновить
63
1.3

Programmer

Отправить сообщение

Да, очень жаль что закрыли.

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

А в gcc свойства насколько я понимаю так и не добавили? Хотя казалось бы там больше всего языковых расширений...

Система выглядит очень приятно! Думаю что вот это все так или иначе пригодится как минимум разработчикам-любителям операционных систем, чтобы не только ядро и консоль, а и красивый GUI был.

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

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

Я тоже когда-то пытался ставить Gnustep на винду (и вроде даже поставил). Меня интересовал язык ObjectiveC, его уникальная в сравнении с другими языками система "сообщений" вместо классических "методов".

Никогда не пользовался, но раз хотят заблокировать - значит стоящая вещь, надо регистрироваться и посмотреть что это такое.

Так пароль нужно еще срисовать. А у меня он хранится в keepass криптоконтейнере. А пароль к криптоконтейнеру - исключительно в голове. А двухфакторная авторизация через sms это зависимость от смартфона, который можно не зарядить, сломать, потерять, украсть, конфисковать, и даже вот так - лишиться возможности получать sms по политическим причинам.

Методы-расширения обобщаются до UFCS, т.е. это должно работать в обе стороны: функция может вызываться как метод от своего первого параметра, и метод может вызываться как функция (статический метод класса) с явной передачей первого параметра. Фича интересная, но почему-то стандартизаторы никак не могут договориться. Хотя казалось бы, всего лишь синтаксический сахар.

А то что у вас в примере - это эмуляция языковых возможностей. Результат ситуации, когда программисты хотят какую-то возможность, язык ее не предоставляет, но зато язык предоставляет слишком большую свободу при использовании других возможностей. И по моему мнению, лучше таких вещей избегать - это нарушает целостное восприятие самого языка, создает многочисленные "диалекты".

Кто нибудь знает, gmail поддерживает TOTP вместо SMS? Еще до всех этих блокировок замечал насколько неудобна вся эта возня со смартфоном и SMS, если нужно к примеру войти в аккаунт из новой виртуалки. Причем аккаунт может понадобиться ради того чтобы через авторизацию гугла войти куда нибудь еще...А теперь, учитывая что в некоторых случаях SMS от Гугла стали не доходить (и вероятно число этих случаев будет только увеличиваться - сначала регистрация, а затем и до авторизации доберутся), вопрос становится более чем актуальным (хотя мне эта 2FA вообще даром не нужна, но раз требуют то напрашивается идея пойти по самому простому пути)

Битовые поля ни в одном языке не сделаны идеально (и это если учесть что они в основной массе языков не сделаны вообще). В Си еще более-менее (хотя и там есть недостатки), в Rust по сути предлагается откат на более низкий уровень - типа сами пишите код для выполнения всех операций с битами. И это только единичные биты, а если нужны битовые типы данных, к примеру беззнаковое число длиной 3 бита, расположенное по строго определенному битовому смещению в слове?

Именно приложение? Т.е. нужен именно смартфон?

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

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

А как это вообще происходит? Что физически покупается, как выглядит сам процесс подключения и использования?

И еще, для того чтобы получать sms на эти e-sim, может есть в природе что-то типа дешевых e-sim gsm модемов? Какой нибудь usb свисток и простейшая софтинка к нему.

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

Да, но изложено очень сумбурно.

Там уже ниже написали, типы рассматриваются как множества значений

Тогда понятно

а у типа-произведения, соответственно, произведение.

Т.е. здесь имеется в виду декартово произведение

Про разные элементы одновременно не понял что вообще имелось в виду

Я просто пытался рассматривать типы как множества полей структур, а не как множества значений.

ИМХО в теории множеств вообще нет аналога для Tagged union. Потому что в tagged union нельзя хранить разные элементы одновременно, а в теории множеств про "одновременность" вообще ничего не говорится.

По поводу пересечения & - вот пример из интернета

type User = {
  name: string;
  age: number;
};

type Employee = {
  name: string;
  department: string;
  salary: number;
};

type CommonUserEmployee = User & Employee;
// Result: { name: string; age: number; department: string; salary: number; }

т.е. на выходе мы имеем тип, объединяющий поля из двух типов, причем одинаковые поля сливаются - в точности как в объединении множеств. A={1,2}, B={2,3}, A∪B={1,2,3}.

Информация

В рейтинге
1 694-й
Зарегистрирован
Активность