warlock13

Машинный код это двоичные данные, которые непсредственно исполняет процессор

Для x86 это и близко не так. Собственно, про это и статья.

Игра вышедшая в продакшн не должна иметь недостающих ресурсов.

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

Кто-то многострочные выражения выравнивает ровно на отступ, кто-то — по семантической позиции в первой строке (грубо говоря, по знаку =).

Smart indentation никак не мешает им это делать. (Ну и не помогает.)

Синтаксический анализатор, вы хотели сказать?

Скорее некое его урезанное подобие.

Вы хотите сказать, что в "любом продвинутом редакторе" есть синтаксические анализаторы для всех хотя бы мейнстримных языков?

С учётом того, что способов оформления блоков кода меньше чем языков — да. (Можно взять два конкретных "любых редактора" — vim и Geany — и убедиться.)

редактор с кодстайлом автоматически унесет фигурную скобку на предыдущую строку, если так сказано в кодстайле.

Так вот перенос скобки — это уже не Smart Indentation.

И как раз от языка зависит, после каких строчек надо автоматически сдвигать блок, а после каких — нет.

Зависит, но только от языка. То есть всё что нужно — это детектор языка, то есть это — возвращаемся к началу обсуждения — может быть (и на самом деле является) фичей любого продвинутого редактора, не привязанного ни к какому конкретному языку (а не IDE, специализирующейся на конкретном языке/наборе языков).

Ну вы правильно описали. Но описанное вами поведение не требует настройки под определённый стиль программирования. То есть вы описали гнутый стиль, но я смогу без проблем тем же редактором с теми же настройками в том же файле писать в стиле K&R. В этом и состоит принципиальное отличие Start Indentation от автоформатирования.

Количество пробелов зависит от ЯП, но фича Smart Indentation — универсальная.

Почему нелепую? Она явно принесла плоды (четыре плюса у поста).

О, я нашёл хорошую формулировку:

Потому что всеобщая радость от победы маскирует продолжающуюся экономическую, социальную, культурную, правовую и политическую деградации России.

Искажаете факты. Подменили утверждение "матч Россия — Испания является позитивным событием" на "матч Россия — Испания был прекрасен".

Какие причины горевать по поводу победы России над Испанией в футбольном матче?

Под статью меня хотите подвести? Не дождётесь. Знаем мы таких, которым всё надо "рассказать подробно".

… что Земля плоская, например.

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

А я вполне компетентен в вопросе, что я должен, а что — нет.

А я не в этом вопросе подвергаю сомнению вашу компетентность. Я сомневаюсь, понимаете ли вы, что нельзя использовать оценочное суждение как аргумент.

почему вы сочли это троллингом

Потому что это подобно заявлению "все мексиканцы — негодяи" в треде, посвящённом обсуждении того, допустимо ли публично говорить что "все люди нации %нация% — негодяи".

Ну, я думал из контекста понятно, что мои знакомые — россияне. Разве нет?

А я не говорил, что "победа России — большая беда". Я сказал, что многие россияне считают, что победа России — большая беда. Вы что, правда не понимаете разницу между этими утверждениями?

Я не испытываю по этому поводу никаких эмоций.

А почему вы должны были бы испытывать какие-то эмоции?

Я не спорил с вами, я просто проинформировал.

Тем более. Для информирования требуется ещё большая компетентность, чем для спора.

И… чем же они мотивировали свою расстроенность?

Это не важно. Я не пытаюсь доказать, что они (и я) правы, а вы — нет. Главное, что есть люди, которые считают так. То есть вы неправы в том, что моё утверждение — чушь.

На второй вопрос я дал ответ выше, добавить мне нечего.

Ну просто это выглядит как "хочу быть дураком и буду" (то есть "хочу не понимать и не буду"). То есть отказ от претензии на обладание необходимой для спора компетентностью. Но поскольку вы при этом от своих тезисов не отказываетесь, то возникает сомнение в том, что именно вы имели в виду — отсюда и мой вопрос-уточнение.

И это будет мегапозитивное событие.

Троллите? Ну-ну.

Что за чушь вы несете?

Почему чушь? Я сам живу в России, я общался с людьми, и многие были расстроены, когда Россия выиграла (а многие — наоборот). Некоторые говорили, что сначала они радовались, но поразмышляв и всё взвесив, они пришли к выводу, что всё-таки успех сборной России — неприятное событие.

Не должен.

Вы не согласны с самим утверждением, что "когда кто-то подаёт политически-ненейтральное оценочное суждение как аргумент, это является ничем иным, как провокацией" или только с тем, что вы не обязаны это понимать?

Мы понимаем, что вы радуетесь, но и вы поймите, что для многих россиян это не радость, это большая беда, неудача. Утверждение "это большая победа российской команды и историческое событие" — фактологическое, с ним проблем нет. И политики в нём нет. Утверждение, что это событие позитивное — это утверждение 1) оценочное, субъективное, 2) имеющее явный политический окрас. А вы его подаёте чуть ли не как истину в последней инстанции. Никто не говорит, что вы не имеете права его произносить, писать. Но вы должны отдавать себе отчёт, что когда кто-то подаёт политически-ненейтральное оценочное суждение как аргумент, это является ничем иным, как провокацией.

И потом, я, например, готов пару минут порадоваться вместе с вами победе. Готовы ли вы погоревать вместе со мной те же пару минут?

Кривая постоянного курса — локсодромия, а дуга большой окружности — это ортодромия.

Для меня самый примечательный момент — это 1) ГГ дожил до пенсии, 2) выйдя на пенсию, он явно не собирается умирать с голоду. Есть ли смысл мечтать о большем?

Хотя я и думал, что будет вполне возможно и интересно декодировать двоичные данные в соответствии с этой замечательной спецификацией

Вполне возможно. Вот мой вариант, без блекджека и шлюх, но зато на Haskell.

1) Выбросить гравиусовские бумажки в море.
2) Играть.

1) Поставить в конструкторе хижину на берегу озера.
2) Создать персонажа-алхимика, подправить стартовые скрипты, чтобы начинать готовым персонажем в хижине.
3) Делать зелья, продавать их, выращивать в огороде ингредиенты. Иногда наведываться в город.

1) Выключить карту.
2) Играть, ориентируясь на внутриигровые указатели. Выучить тропинки Эшленда, научиться на глаз отличать фояды.

1) Выяснить, сколько километров от Балморы до Кальдеры.

...

Так можно не пройти игру за двенадцать лет.

Я боюсь, что использование Equals решает эту проблему, только если требовать обязательность указания метода сравнения, но в Java, если не ошибаюсь, этого нет. Лично я считаю, что если уж делать всё совсем правильно, то должны быть два разных типа для строк — "культурные" и "бескультурные", чтобы их нельзя было незаметно перепутать. Тогда для второго типа можно иметь обычное простое сравнение, а для первого надо обязательно требовать передачу способа сравнения. Но и в текущей ситуации есть свои плюсы.

В подавляющем большинстве случаев требуется максимально простое, быстрое и тупое сравнение, которое 1) даёт предсказуемый результат для ASCII-символов, 2) даёт true для в точности одинаковых строк, 3) желательно даёт false для хоть сколько-нибудь различных строк, 4) не зависит ни от каких культур. И да, в C# оператор == для строк именно таков.

У меня почти идеальное совпадение в обоих случаях. В первом я оценил как 50%, расчёт даёт 43%. Во втором оценил как 25%, расчёт даёт 30 — 50% при условии, что отношение вероятностей заболеть не превышает 2 (при разнице в два раза как раз и получается 30%).
(Правда я не совсем уверен, что правильно интерпретировал понятие точности теста, но вроде правильно.)

В жизни проводить такие расчёты крайне затруднительно, потому что отбросить эмоции нереально. В связи с этим, очень жалею, что не вулканец.

Я не понял, так нашли того, кто сливал инфу или нет?

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

Red Hat доказала, что это жизнеспособная бизнес-модель, что это лучший способ распространения ПО и что на этом можно хорошо зарабатывать

И чуть дальше:

Red Hat действительно уникальна

Что-то здесь не так.

Что файловый менеджер будет делать с Makefile? Например, показывать иконку, выполнять определённое действие при даблклике. Суть в том, что иконка и действие будут разными на одном и том же файле, но который называется по-разному (Makefile и just_some_text).

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

В линукс — операционка вообще не смотрит на расширение. Она смотрит на права доступа и на заголовок файла внутри.

Смотрит. Только не операционка, а файловые менеджеры, и не на расширение, которое существует только неформально, а вообще на имя файла (например, Makefile является text/x-makefile, но если его переименовать — будет просто text/plain).

Что касается конструктива — ну я же не могу знать, что для вас важно, а что нет, поэтому не могу сказать заранее мой совет полезным. Априори я исхожу из того, что человеку на свою карму не плевать.

Ну и, наконец, "выкиньте свой текстовый редактор" — это вообще-то не совет, и даже не рекомендация. Это просто сокращённый вариант для "это программа безнадёжна, не стоит принимать её существование во внимание"

Нет, ОС (и их встроенные файловые менеджеры) этим как раз отличаются — одни смотрят на расширения больше, другие меньше — что ж тут такого? Равно и невстроенные файловые менеджеры — естественно, они смотрят на расширение. Это программы, работающие с файлом "снаружи". Но когда файл "ушёл" к программе, которая предназначена для работы с файлом "изнутри", программа должна смотреть именно на контент, а на особенности названия файла (а расширение — это часть названия, даже в Windows, где она более особенная часть) если и смотреть, то в самую последнню очередь и только если действительно надо. Если этого не придерживаться, то легко можно получить ситуацию, когда абсолютно валидный файл не открывается какой-то программой, которая умеет с ним работать, но не может, потому что файл называется, не так, как она (программа!) хочет. Собственно поэтому так и не делают, и вы можете назвать файл с matroska video внутри video.avi и открыть его любой программой, и ни одна даже не пикнет.

Скрипт, особенно библиотека, может вообще не содержать никакого #!, как тогда будет вести себя ваш умный редактор?

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

Если у скрипта не стоит расширение, то во многих редакторах автоматически не включится подсветка.

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

Не могу ничего утверждать, и выиграть рандомно действительно не так-то просто (меня обмануло то, что моя первая же попытка после прочтения этой статьи удалась, но это, видимо, случайность). Но 2048 я рандомно ни разу не собирал, а Fe[26] минимум дважды всё же получилось.

1) Статья — супер, но если бы мог, то поставил бы минус за bash-центричность: скрипты с шапкой "#!/bin/bash" (по крайней мере у меня) вызывают омерзение, правда к большому сожалению read с таймаутом в линксовом sh нету (во фряшном есть); и вместо того, чтобы разбираться с автокомплитом в bash, не лучше ли перейти на zsh и разбираться уже там с автокомплитом?.
2) В разделе про dd стоило бы упомянуть вариант создания файла с "дыркой" — не всегда при создании файла нужного размера требуется обязательно аллоцировать реальное место.

Мне кажется с режимами небольшая неразбериха (ещё с комментов к предыдущей статье). Постоянно звучит, что "для того, чтобы переместить курсор, надо нажать Esc, потом перевести курсор (например, j), а затем нажать i для возвращения в режим редактирования".
Я не знаю, может вимеры так и работают, но по-моему это подход шиворот-навыворот и в самом деле неудобно. Когда мне нужно перевести в виме курсор, я просто нажимаю нужную клавишу (например, j). Никаких Esc, никаких i. Вот когда мне нужно что-то напечатать — вот тогда я нажимаю i (или A или r и т. п.), потом печатаю, потом нажимаю Esc. Понимаете разницу?

Она очень проста: надо рандомно жать стрелки туда-сюда и почти наверняка выиграешь. С 2048 это не работает.

для написания романа — текстовым процессором

И этот человек смеет что-то говорить про "использование оптимальных инструментов"?

Почерк не изменился, но внезапно улучшились навыки игры на электрогитаре. Но, думаю, всё-таки совпадение.

А ещё в программу заложены правила записи числ цифрами и сложения чисел. Значит ли это, что при сложении чисел важно правильно записать исходные числа (ну скажем, не вводить 3+3, если хочешь сложить 2 и 2), а то программа сама решит как лучше складывать числа?

При множественном возведении числа в степень важно расставить нужным образом скобки, а то программа сама решит как лучше группировать.

Чушь. Программа ничего не группирует, она просто делает то, что вы скажете. В следующем примере вы приказываете ей посчитать , и она так и делает.