Вот вам очевидно, что когда на тело не действует сила, то оно движется равномерно или находится в покое. Потому что вам известен курс элементарной физики и вы решили много задач по теме. А вот Аристотелю — нет.
Я бы назвал это логичным, но ни как не очевидным. Например, так ли очевидно, что в искривленных пространствах на тело, на которое не действует никакая сила, будет оставаться в покое или двигаться равномерно? А если пространство не просто выпукло/вогнуто (если это можно так назвать), а скручено? Где-то даже читал, что наше пространство может быть таким.
Я довольно часто вижу, что за рубежом говорят: “Так классно, спасибо. Ты же еще и время на это потратил”. А в России: “Ой, это же каждый знает, всё итак понятно”.
В данном контексте я бы рассматривал эти фразы, как показатель компетентности среднего разработчика. Если на этом вашем западе хвалят такую статью, то я сильно сомневаюсь в профессионализме хвалящего. Ибо это такие основы, которые просто стыдно не знать.
Другое дело, если бы были показаны типичные (или наоборот, нетипичные, но весьма занимательные) ошибки, когда ошибка в одном месте приводит к сообщению об ошибке в другом. А также как восстанавливать реальное положение ошибочного кода (вообще я сомневаюсь, что это возможно в такой постановке). Сам я зашел сюда только за этими советами, а их и нет — одна вода, «если забыли кавычку, поставьте кавычку, забыли скобку — поставьте скобку».
P.S. Все замечания по контенту можете отправлять в оригинал статьи, здесь только перевод.
Ну почему же. Если вы уже решились на перевод, то должны понимать его ценность. А если ценности нет никакой, то может ну его, этот перевод? И поискать что-нибудь покачественнее?
Пожалейте же читателей кода! Зачем лепить километровые предложения template<...> на одну строку с самим типом/функцией? Ну проще же читать, когда можно разделить эти сущности визуально.
Эльфам — Три Кольца — во владенья светлые.
Гномам — Семь Колец — в копи горные.
Девять — Людям-Мертвецам, ибо люди — смертные.
И Одно — Владыке Тьмы, в земли черные — В Мордор, куда сходятся Силы Тьмы несметные.
В том одном Кольце — сила всех Колец,
Приведет в конце всех в один конец — В Мордор, куда сходятся Силы Тьмы несметные...
В этом переводе, кстати, названия книг удачно переведены, не то, что выбрали для фильмов — там сильно хуже. Сравните:
Дружество Кольца — Братство Кольца (какое братство? Хранители связаны дружбой, а не кровными узами — отсюда и название, и на Совете в самой же книге ему дано исчерпывающее объяснение)
Две твердыни — Две крепости (крепостей кругом навалом, а вот Твердынь… уже само слово намекает на их неизменность, непоколебимость, тысячелетнюю историю)
Возвращение государя — Возвращение короля (опять же, король — это титул, каждый носить может; государь — призвание, вождь, удел избранных. Так кто вернулся на трон?)
PS. К слову о кольцах… их можно найти в той переплетащейся хреновине, которая не так давно была символом сайта. Сам вимвол круглый — это то самое Одно. Хм…
Или хотя бы поиск чтобы по всем ресурсам сразу работал. Ну и как совсем несбыточная мечта — если в результатах поиска не найдено в одном разделе (в топиках, например), но найдено в другом (в комментариях) — автоматически переключать вкладку на ту, где что-то найдено. Заколебался по нескольку раз ссылки с баша искать!
Да, разумеется, это очень нужно! На курсах компьютерной графики нам говорили, что постоить матрицу перспективного отображения нельзя, так как оно не является афинным преобразованием, а матрицы только такие и описывают (если ничего не путаю). У меня это всегды вызывало недоумение: как же так, а как тогда все игры работают?
А вот оказывается, что на самом деле не такое уж там и перспективное отображение используется…
С датами соглашусь, а что в вашем понимании ссылки? Ссылка — по определению непредставимая сущность в человекочитаемом формате. Так как она означает «пойди туда, куда я показываю, и прочитай то, что там написано, а потом вернись сюда». Не человекочитаемо ни разу. Все ссылки эмулируются через другой тип данных — будь то номер или мнемоническое имя в определенном массиве.
А также наличия не только предиката «равно», а ещё и предикатов «больше», «меньше» и других.
Что-то не очень понимаю, о чем вы. Какие в формате данных могут быть предикаты? Предикат — это поведение, определяемое конкретными типами выражения в предикате. А есть такие типы в JSON, где есть предикат «равно», но нет «больше» и «меньше» и каких-то «других» (каких?)?
Но для non-tree языков это действительно годится — не приходится дополнительно экранировать символы вложенного языка.
Неправда, теперь вам придется экранировать символы уже обоих языков. Без экранирования можно обойтись только в одном случае — когда перед данными идет их длина. Но это сразу делает формат человеконередактируемым (чтобы исправить что-то в одном месте нужно внести как минимум одну правку еще в другом).
А с другой стороны, когда у вас куча никак не связанных между собой типов данных, начинается каша, начиная от банального, «как их сравнивать?» (читай — упорядочивать); как определить, это одно и то же значение или нет (читай — как проверять эквивалентность).
Кому-то не хватает этих пресловутых 6 типов данных (хотя согласен, разделение int/float было бы уместно)?
Не нужно путать понятия «прочитал» и «еще читает» (а еще читает потому, что другая сторона еще пишет). Соответствие спецификации указывается для готовых документов, а ни как для их частей.
Если ограничить скорость перелистывания, боюсь, и прочитать за сутки книгу будет проблематично :( А если времени хватит на прочтение всей книги, то для её копирования методом «снимаем экран на мобильник» хватит и подавно.
В нормальных системах файлы логов ротируются — прочитать за раз файл лога в несколько гигабайт несколько проблематично. А если читать частями, то какая разница, валидный у него конец или нет?
Любой парсер, пока разбирает файл, работает с неполной структурой — неважно, в памяти она уже вся или дочитывается по требованию. «Не особые» парсеры просто по окончании разбора имеют неотключаемую проверку валидности, без которой можно и обойтись. Опять же, эти «не особые» парсеры в принципе нельзя использовать для данных, которые постоянно дописываются — они работают только со статическими данными, а они подразумеваются корректными (лог закрывается, окончание, требуемое спецификацией, в него дописывается => он становится валидным).
Отличие от вашего формата только в том, что для него нельзя постоить «не особый» парсер — все будут «особыми». Ну как бэ к формату данных это отношение не имеет.
Говорить о том, можно ли называть файл XML или нет, можно только после того, как он будет сформирован полностью. А пока мы его не закончили, вопрос висит в воздухе (естественно, если мы пишем валидные части XML, если записали уже что-то невалидное то и результат будет невалидным). Поэтому вполне можно называть этот файл XML-ом.
2. Вы не заметили, что кроме поточного чтения, есть ещё поточная запись. Логи, поток сообщений и тп.
Ну так и что? Файл же (или куда вы там пишите) когда-нибудь закончится, и в конец запишутся все требуемые спецификацией окончания. Вы же все равно с другого конца тоже поточно читаете. Так какая разница, до начала чтения существовал весь файл или нет. А если чтение не поточное, так извольте дождаться, пока все данные будут записаны, в том числе и окончания (для читающего вообще нет надобности в этом случае ждать, что там пишется в данный момент — файл или записан или нет, это все, что его волнует).
Вы слишком преувеличиваете необходимость иметь структуру данных, точно соответствующую спецификации, в любой момент времени
Ну как бы поточность в основном и используется для необратимых действий. Зачем строить структуру, если она сразу же будет разрушена? А вот наличие обратных ссылок — вот это уже действительно проблема для поточной обработки, универсального решения для которой нет.
Пробел и таб — это пустое место и воспринимается, как пустое, ничего не значащее место. Форматирование отступами — это представление содержания, View из MVC, если так понятнее. А скобочки — это Model. Зачем смешивать одно с другим, когда все вокруг твердят о том, что их надо разделять, я не понимаю.
Интерпретатор питона, насколько я знаю, приравнивает таб к 4 пробелам. Если в вашем примере перед y будет табуляция, а перед z — два пробела, а редактор показывает табы, как 2 пробела, то точно так же 90% прочитают код неправильно.
Не понимаю, почему разделители вдруг становятся лишними элементами. Все равно, что писать без знаков препинания. Вот, например (статистики, конечно, нет, но думаю, не слишком погрешу против истины), наверняка большинство программистов предпочитают явные приведения типов взамен неявных. Особенно, если сталкивались с ситуациями, когда компилятор не согласен с тем, что думает программист. В некоторых языках (enum1 к enum2 или int в C#, например) вообще запрещено неявное приведение одних типов к другим (явное возможно).
Почему же с такими простыми истинами многие соглашаются, но могут утверждать, что явное выделение блока кода фигурными скобочками — зло?
Я бы назвал это логичным, но ни как не очевидным. Например, так ли очевидно, что в искривленных пространствах на тело, на которое не действует никакая сила, будет оставаться в покое или двигаться равномерно? А если пространство не просто выпукло/вогнуто (если это можно так назвать), а скручено? Где-то даже читал, что наше пространство может быть таким.
В данном контексте я бы рассматривал эти фразы, как показатель компетентности среднего разработчика. Если на этом вашем западе хвалят такую статью, то я сильно сомневаюсь в профессионализме хвалящего. Ибо это такие основы, которые просто стыдно не знать.
Другое дело, если бы были показаны типичные (или наоборот, нетипичные, но весьма занимательные) ошибки, когда ошибка в одном месте приводит к сообщению об ошибке в другом. А также как восстанавливать реальное положение ошибочного кода (вообще я сомневаюсь, что это возможно в такой постановке). Сам я зашел сюда только за этими советами, а их и нет — одна вода, «если забыли кавычку, поставьте кавычку, забыли скобку — поставьте скобку».
Ну почему же. Если вы уже решились на перевод, то должны понимать его ценность. А если ценности нет никакой, то может ну его, этот перевод? И поискать что-нибудь покачественнее?
В этом переводе, кстати, названия книг удачно переведены, не то, что выбрали для фильмов — там сильно хуже. Сравните:
PS. К слову о кольцах… их можно найти в той переплетащейся хреновине, которая не так давно была символом сайта. Сам вимвол круглый — это то самое Одно. Хм…
А вот оказывается, что на самом деле не такое уж там и перспективное отображение используется…
Что-то не очень понимаю, о чем вы. Какие в формате данных могут быть предикаты? Предикат — это поведение, определяемое конкретными типами выражения в предикате. А есть такие типы в JSON, где есть предикат «равно», но нет «больше» и «меньше» и каких-то «других» (каких?)?
Неправда, теперь вам придется экранировать символы уже обоих языков. Без экранирования можно обойтись только в одном случае — когда перед данными идет их длина. Но это сразу делает формат человеконередактируемым (чтобы исправить что-то в одном месте нужно внести как минимум одну правку еще в другом).
Кому-то не хватает этих пресловутых 6 типов данных (хотя согласен, разделение int/float было бы уместно)?
Любой парсер, пока разбирает файл, работает с неполной структурой — неважно, в памяти она уже вся или дочитывается по требованию. «Не особые» парсеры просто по окончании разбора имеют неотключаемую проверку валидности, без которой можно и обойтись. Опять же, эти «не особые» парсеры в принципе нельзя использовать для данных, которые постоянно дописываются — они работают только со статическими данными, а они подразумеваются корректными (лог закрывается, окончание, требуемое спецификацией, в него дописывается => он становится валидным).
Отличие от вашего формата только в том, что для него нельзя постоить «не особый» парсер — все будут «особыми». Ну как бэ к формату данных это отношение не имеет.
Говорить о том, можно ли называть файл XML или нет, можно только после того, как он будет сформирован полностью. А пока мы его не закончили, вопрос висит в воздухе (естественно, если мы пишем валидные части XML, если записали уже что-то невалидное то и результат будет невалидным). Поэтому вполне можно называть этот файл XML-ом.
Ну так и что? Файл же (или куда вы там пишите) когда-нибудь закончится, и в конец запишутся все требуемые спецификацией окончания. Вы же все равно с другого конца тоже поточно читаете. Так какая разница, до начала чтения существовал весь файл или нет. А если чтение не поточное, так извольте дождаться, пока все данные будут записаны, в том числе и окончания (для читающего вообще нет надобности в этом случае ждать, что там пишется в данный момент — файл или записан или нет, это все, что его волнует).
Вы слишком преувеличиваете необходимость иметь структуру данных, точно соответствующую спецификации, в любой момент времени
Интерпретатор питона, насколько я знаю, приравнивает таб к 4 пробелам. Если в вашем примере перед y будет табуляция, а перед z — два пробела, а редактор показывает табы, как 2 пробела, то точно так же 90% прочитают код неправильно.
Что делать, если компилятора нет, а ошибку исправить надо?
Почему же с такими простыми истинами многие соглашаются, но могут утверждать, что явное выделение блока кода фигурными скобочками — зло?