Pull to refresh
4
0
Владимир@VMarkelov

Пользователь

Send message
По тону статьи мне казалось, что она рассказывает про настоящие случаи, когда слова становятся контронимами. Поэтому для случаев, когда слово контроним себе только в разговорном языке и то не у всех, хорошо бы об этом сказать, а не укоренять некорректное использование и дальше. Думаю, если бы несколько лет назад(до обновления правил русского про «кофе») писали статью про русские «странные» слова и упомянули, что кофе имеет сразу два рода: мужской и средний, то было бы много гневных комментов на тему распространения безграмотности. Примерно тот же случай и здесь.

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

Насколько я помню, в разных статьях это упоминается как частая ошибка. Literally != фигурально. И хоть так используют в разговоре — это не стандарт языка. Например:

writingexplained.org/literally-vs-figuratively-difference
По первой же диаграмме сразу вопросы:

1. Заведена переменная A, которая только сравнивается с 3 минутами. Где она изменяется? Если ответ в блоках «4c», то как догадаться, что «4с» изменяет именно переменную А? И что по поводу остальных блоков типа «2м48с» — они тоже какую-то переменную меняют? Как диаграммное программирование при таком раскладе(при условии, что имя изменяемой переменной скрыто) исключит изменение не той переменной?

Я уж молчу, что обычному человеку-непрограммисту, за которого тут много написано, было бы проще читать без загадочных «A := 0» и «А > 3 мин». Можно их обоих заменить на более понятное условие «Если с начала проверки двигателей прошло больше 3 минут».

2. Алгоритм небезопасный и с ним Боинг точно также бы и разбился. Вот почему я так думаю: мы 3 минуты тестируем двигатели. Если за 3 минуты ни один из двигателей не в норме, мы вместо того, чтобы отправится на ремонт/диагностику, просто врубаем фотонный двигатель(приговаривая «авось пронесёт»), и дальше — взрыв.
И мне так кажется, что подобный баг пропустить на развесистой диаграмме не сильно сложнее, чем в обычном «текстовом» описании алгоритма.
Из статьи мне показалось, что «200 000 евро убытков» не совсем отражает реальность. Тут тоже самое, что и за пиратские фильмы насчитывают миллионы упущенной прибыли. Автор высчитывает убытки исходя из «а вот если бы я работал и мой постоянный доход был таким». В итоге и выводит красивую большую сумму в 200 тысяч. Я не говорю, что автор ничего кроме времени не потерял, но для меня «упущенная прибыль» и «убытки» это очень разные вещи. В реальности и доход у него мог быть меньше и работы не каждый день, что дало бы меньше 200 тысяч. Хотя, соглашусь, мог заработать и больше 200000.
Ради справедливости замечу, что TOML — язык без значимых пробелов. Вот комментарий из его родного примера:
# Indentation (tabs and/or spaces) is allowed but not required

Взято отсюда: github.com/toml-lang/toml#example
Также ложность постановки вопроса заключается в том, что ½:½ — это якобы неполноценная партия, в отличие от 1:0.


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


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

Есть конечно и обратное: в хоккее нет ничьих, там играют до победного. В целом тоже не плохо и вполне себе работает. Правда, когда на кону один единственный гол(в добавочном тайме), то команды могут начать играть через чур осторожно, что сказывается не в лучшую сторону.
Считаем: 2 в 100 степени — это примерно 1.27 x 1030 или 1,267,650,600,228,229,401,496,703,205,376 вариантов.

Теперь нашему суперкомпьютеру на перебор всех вариантов понадобится примерно 4.6*10^+35 (4.6 на 10 в 35 степени) лет.


Не понятно, как так выходит, что «примерно 10^30 вариантов» суперкомпьютер будет считать «примерно 10^35 лет». Один вариант за 10^5 лет? Вручную быстрее, наверное, все варианты написать :)
Про парсинг я и не спорю. Визуально-то оно понятно. Но в ключе обсуждения:
основой такого языка должны стать только правила пунктуации

тут у нас не будет никаких знаков препинания, кроме точки. Отсюда вопрос, как же будет работать основа, которая далеко не у всех естественных языков основа. Конечно, можно сказать, что «а пусть пишут на английском», но тогда ради чего огород городить? Да и часть статьи явно о том, что хорошо бы писать на любом естественном языке.
По мне так, несколько утопичненько :) Скорее всего, будет сильно упрощено ради того, чтобы хоть как-то работало. Что не понравится ни обычным пользователям, ни программистам. Как говорится, за двумя зайцами погонишься,…
Добавочно смущает наличие слова «естественном» в кавычках при описании языка. То есть, он будет квази-естественнным. Опять же не ясно до какой степени, и для какого контингента это будет интересно.

Так как каждый пользователь является носителем своего родного естественного языка (или даже нескольких), то жестко задавать ключевые слова невозможно, из чего следует, что основой такого языка должны стать только правила пунктуации, но никак не лексика или грамматика.

Что насчёт языков, что крайне скупо используют знаки препинания? Этим часто страдают агглютинативные языки, в которых, например(реальная ситуация при переводе из такого языка), фраза визуально из двух слов, оканчивающая точкой, в русском разворачивается в такую штуку с кучкой запятых: «в то время, когда он читал, она спала». Эдакое описание параллельных вычислений на «живом» языке :)
Кстати, дополнительный вопрос: «Как на человеческом языке описывать многопоточное программирование и всякую асинхронщину?»

Компилятор/транслятор должен уметь преобразовывать исходный текст программы не только в машинный код для компьютера, но в другой вариант «естественного» языка, чтобы пользователь мог работать с исходным текстом на известном ему «естественном» языке.

Общий смысл высказанного мне видится, как «Надо бы сделать google translate», только чтобы он еще и из текста мог программу сваять, причём, чтобы она делала то, что хочу.
FAR тут ни при чём — это проблема всех приложений, ибо есть висящий тикет на гитхабе, чтобы новый терминал стал передавать события мыши запущенным приложениям: github.com/microsoft/terminal/issues/376

Так что, если мышь нужна, то тут, к сожалению, либо cmd, либо powershell, думаю.
Я на Амазоне потреково покупал и после покупки можно скачать (я качал в mp3 320, но там мож и flac есть — мне mp3 хватает)
По-моему, метод poker planning — хороший способ погрязнуть в фичах, которые никому не нужны и далее участь проекта может стать незавидной(а то и похоронить его после неукротимого разбухания):

Команде ставится условие: 1 палец — фича не очень, 2 пальца — фича норм, 3 пальца — фича просто бомба


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

Я понимаю, что там есть ещё множитель «сложности». Но при равных сложностях выигрывают фичи, «любимые» командой, а не те, что нужны для успеха продукта. Хотя, часть фич может и совпасть.
Для Go только первый вариант рабочий. Так что, сначала надо определиться с языком, а потом уже переформатировать :)
С этим вариантом одно плохо: не для всех языков подходит(замечу, что тэга С/С++ у статьи нет, значит она про все языки). А именно для языков, которые считают, что точка с запятой не нужна. Вот, скажем, для Go такой вариант будет как раз вредным советом, ибо компилятор тут же выкинет нечто вроде(Go не понимает тут, где строка кончается):

./prog.go:10:10: syntax error: unexpected ||, expecting }
Про субтитры — это только так кажется, что без них сложно :) Если что, я сам такой: обычно смотрю с субтитрами и думаю, что без них вообще ничего не понял бы. Но, стоит попасть на не очень затягивающий фильм, я начинаю отвлекаться от экрана(поглядывая в полглаза чисто на картинку, не вчитываясь в субтитры), и о чудо! Я, оказывается, могу и на слух понимать достаточно много, чтобы фильм оставался понятным и линию сюжета я не терял. Можете попробовать :) Я на особо скучных фильмах(было только интересно, что будет в итоге) даже пасьянс запускал и сбоку от фильма раскладывал — субтитры тогда вообще не читал, но картинка была видна для слежения за сюжетом.

Хотя, признаюсь, несколько фильмов без субтитров я не потянул вообще. В одном был сильный техасский акцент, как я понял. Другой был переполнен сленгом подростковым. Остальные не скажу, что подвело.
Да, возможно. Спасибо за подсказку. Тогда просто «стабилизировался» хватило бы. А вот «быстро возвращается» — это как-то звучит тоже слишком уж по «PR-щически» бездоказательно. Хотелось бы знать, в чём именно проявляется «быстрота» этого возвращения :) Раз уже автор это упомянул.
Биток же, не спеша, периодически подскакивает до ~9500, потом возвращается до ~9000 уже какой месяц подряд. Я, правда, не в теме, и может именно сейчас там что-то происходит, но со стороны обычная(в каком-то смысле) стабильность.
Тем не менее, в настоящий момент Bitcoin быстро возвращается в нормальное состояние, поэтому сейчас самое подходящее время


Вот эта тема не раскрыта. Сколько смотрю цены на него, уже сколько месяцев он болтается в районе 9000 за штуку. Где же «быстрое возвращение»? Или тут имелось в виду что-то другое?
В том числе автодополнение имен файлов для системных утилит вроде cd? Не первого попавшегося файла с подходящим началом, а всех


Да, есть такая проблема — увидеть все подходящие. TAB-TAB просто по циклу подставляет все подходящие по очереди. В моих случаях этого достаточно, ибо я сразу набираю первые N достаточно уникальных символов. Скажем в папке rust проекта при наборе «git add C» и тут же TAB, мне сразу подставляется первый по алфавиту Cargo.lock. TAB еще раз и он меняется на Cargo.toml. Всё, два TAB-TAB и готово. Согласен, не очевидно и без полного списка не так удобно. Но выбрать всё ж можно не только первый подпавшийся.
то с другими базовыми вещами вроде копирования-вставки, сохранения истории и автоподстановки по TAB? Ну и, хотя сам я не пользуюсь, но alias'ы команд тоже многим нравятся.


На мой взгляд, это вообще-то не функции терминала. Это дело того, что внутри терминала бежит. В том же упомняутом konsole, если в одной вкладке bash, а в другой zsh, то сомневаюсь, что у них будет одно поведение и общая история. История и TAB — это дело cmd/powershell и что там еще запускается.

Правка: в том powershell TAB вполне себе работает. Если программа озаботилась поставлять файл для completion в виде ps1 файла. Без них powershell вполне неплохо подсказывает пути и внутренние команды
Переименование и цвета для вкладок вроде и хорошо. Но при долгом использовании, думаю, что буду использовать это редко. Причина:

> Цвета для каждой вкладки будут сохраняться в течение текущего сеанса
> ввести свое название для текущего сеанса

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

Information

Rating
Does not participate
Registered
Activity