Интересно, а зачем с точки зрения дизайна языка вообще ввели отдельно null и отдельно undefined? Не проще ли было обойтись каким-то одним? Для реализации абстракции опционалов вполне достаточно одного.
В этом есть какой-то глубокий (основанный на какой-то умной околоматематической теории) смысл, или просто так сложилось/не сложилось?
Не, не секреты. Проекты простейшие. Там именно что-то с работой gradle и его файлами. И даже было такое, что компилятор или какой-то другой инструмент сборки падал на каких-то файлах (Execution failed for task ':app:processDebugMainManifest'), при этом AndroidStudio выдавала подсказки что нужно исправить. Вообще все это создает впечатление полнейшей несогласованности набора инструментов. Даже вот пункты меню типа "Sync project with Gradle files" - это вообще что? Правая рука не знает что делает левая? Сама АндроидСтудия как IDE - просто отличная, никаких нареканий; но им бы открутить все эти сборочные поделия и написать полностью свою интегрированную в IDE инфраструктуру сборки проектов, в идеале основанную на простых "файлах проектов" (xml как в Visual Studio) без всякой императивщины (да, я считаю что любые активные скрипты в файле проекта - зло, и в 99% не нужны, достаточно просто списка файлов исходников и перечня опций компилятора, а там где нужны, должны быть огорожены специальными тегами наподобие prebuild_action / postbuild_action).
У меня есть некие собственные впечатления о разработке под андроид. Я на чем только не писал, однажды решил ради интереса попробовать и под Android. Сам язык (Java или Kotlin) никаких проблем разумеется не вызвал, после С/С++ и общих представлений о множестве других языков. А вот что не понравилось, так это тотальная зависимость Android Studio (а конкретно системы сборки Gradle) от интернета. Если интернет не совсем обычный (хитрые корпоративные политики безопасности на шлюзе) или его вообще нет, оно не работает. Если интернет есть и обычный - оно лезет туда на каждый чих и что-то скачивает. Создает какие-то кэши скачанного, которые очень быстро раздуваются до гигабайтных размеров. Это печально, коробочные продукты в которые "все включено" гораздо приятнее.
Еще: если допустим скачиваешь чей-нибудь проект с гитхаба, написанный для Visual Studio (С++, C#), или для Qt - проблем со сборкой как правило нет. Даже проекты олдскульного Visual Studio 6 1998 года конвертируются в форматы любых современных студий. Здесь же - сразу какие-то заморочки, и обычно ничего не собирается, по причинам загадочным и не имеющим отношения к синтаксическим ошибкам в коде. Т.е. программист, вместо того чтобы думать об абстракциях кода, вынужден будет заниматься каким-то шаманством непонятно с чем. Это печально, и еще раз наводит на мысли о принципиальной неправильности самой концепции "систем сборки" как таковых.
Что касается GUI, то могу только сказать - да, есть некая специфика, интуитивно она мне не очень понравилась, но я особо и не разбирался. Допускаю что все это нужно для универсального описания GUI, способного работать на произвольном размере экрана и с произвольными настройками пользователя.
А внутри горизонта событий можно двигаться в произвольном направлении (в том числе и от центра черной дыры, в стороны и т.д.), или только строго к центру? Что говорит об этом математика?
Гитхаб тут недавно подложил свинью в виде обязательной двухфакторной аутентификации. Вбитые в гит ключи пока работают, а на сайт без 2FA уже не попасть:( Вот зачем оно мне, если я использую гитхаб только как хранилище личных заметок и исходников нескольких личных же утилит? Не знаю что и делать, то ли изучать этот вопрос (как обойти минимальными затратами), то-ли отказываться от гитхаба. И отказываться не хочется, у меня были планы насчет их github.io pages...
Очевидно что есть ПДД, которые нужно соблюдать. И если принять что техника исправна (т.е. мы исключаем фактор неисправной техники - он всегда был, и задолго до ИИ, к примеру отказали тормоза), то получается, что автопилоту точно известны места и условия, где к примеру пешеходы могут переходить дорогу, и где не могут. Поэтому если так сложилось, что пешеход выскочил ночью из леса на проезжую часть, где нет переходов и светофоров, и автопилот уже не может безопасно затормозить или изменить траекторию, то такой пешеход будет сам виноват, если его задавят. Будь он хоть трижды лауреат Нобелевской премии с тридцатью тремя детьми.
При условии стопроцентного соблюдения правил всеми участниками, и при условии исправной техники, аварии полностью исключены. Поэтому, при условии исправной техники, в любой аварии всегда виноват конкретный человек. Именно это и должно быть критерием в "проблеме вагонетки".
Интересная и объемная статья. Когда прочитал "Лабиринт отражений" (лет 20 назад?), сразу пришла в голову мысль: а что если использовать обычный, классический гипноз для погружения человека в виртуальный мир компьютерной игры? Понятно что никаких "deep" эффектов в реальности нет, но ведь гипноз-то вполне себе есть. Кажется, даже написал автору на какой-то форум, он ведь по первой профессии психиатр, по идее это ему должно быть хоть немного знакомо.
И еще. Вот эта тема меня очень интерсует:
В детстве, когда у нас не было никакого опыта мы смотрели на всё свежим взглядом. Казалось, что день длится целую вечность, трава зелёная, небо голубое, а деревья большие. В таком состоянии любая самая обыденная для взрослого вещь вызывает интерес — например, палка, которой можно рубить крапиву как мечом. Для взрослого это просто палка. Для ребенка — артефакт из мира воображения.
В детстве действительно восприятие гораздо более яркое и насыщенное. Эффект погружения практически от всего, будь то игрушки, примитивно нарисованные мультики или просто цветные камешки на земле. И вроде все об этом знают, но мне интересно - есть ли какие-то научные исследования на эту тему? Как с точки зрения науки вообще называется это детское восприятие? Можно ли его достичь во взрослом состоянии? Есть ли, к примеру, препараты, изменяющие работу мозга так, чтобы взрослый мог вернуться в это состояние? (нет, экспериментировать над собой с препаратами не планирую, но интересна любая научная информация по этой теме).
У меня в заметках числятся две вещи, которые нужно до вас донести в комментариях к первой же статье:) Вот они:
Адресная строка и punycode. Например, видим в адресной строке https://ru.wikipedia.org/wiki/Заглавная_страница а если скопировать это в буфер обмена и затем вставить в любой текстовый редактор, то получим там вот это https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0 Зачем так сделано? Я часто вставляю ссылки в документы, в текстовые файлы, в исходники и в прочие места, и хочу видеть там человекочитаемый текст, а не закодированный в 6 раз длиннее. Или хотя-бы сделайте настройку, в каком виде копировать адресную строку в буфер обмена. (я это обхожу пока так: копирую ссылку без первой буквы h, тогда она нормально копируется, а затем букву дописываю вручную)
Случайное удаление плиток с сайтами и группами со стартовой страницы. Удалить плитку очень просто случайным щелчком по "минусу" в правом верхнем углу плитки. А восстановить - невозможно (особенно если там целая папка, в которой много ссылок, это по памяти уже точно не восстановишь). Сделайте хотя-бы диалоговое окно "Вы уверены что хотите удалить?".
Список команд, но не список файлов. Geany сохраняет в своем "проекте" список файлов, открытых в редакторе, а это не то: в проекте (как абстракции разработки) запросто может быть больше файлов, чем открыто в редакторе, и в редакторе запросто могут быть открыты файлы, не относящиеся к текущему проекту.
Идея то ведь простая. Есть группа файлов (располагающихся где угодно, не обязательно в одной директории), которые я в рамках какой-то работы хочу иметь всегда под рукой в виде списка (а лучше дерева с "виртуальными" папками) в панели слева. Открывать их оттуда щелчком мыши, а при закрытии закладки с этим файлом он не должен пропадать из списка. Ровно это делается во всех IDE, в частности в Visual Studio, Qt Creator и т.д. Но в Geany этого нет, поэтому Geany все-же остается текстовым редактором, а не IDE.
Можно предложить такую формулировку: "перевести на тот язык, который будет понятен всем участникам команды". И если там есть непонятные термины предметной области, без которых никак - то их задача разжевать эти термины (в том числе уточняя у заказчиков, консультантов, в специальной литературе и т.п.) и оформить эти разъяснения документально, причем все это следует обсуждать и делать вместе с программистами.
А зачем тогда нужны все эти продакты, проджекты, менеджеры и аналитики? Кажется это их задача: выяснить чего в точности хочет заказчик, перевести эти пожелания с языка предметной области на общечеловеческий, и оформить этот перевод в виде документа - задания программисту. А программист уже переводит с общечеловеческого на язык машины/ОС/фреймворка и т.п.
Хорошая софтина. В линуксе ей пользуюсь как текстовым редактором. Но кажется, у них не было понятия "проекта" (как отдельного файла со списком файлов исходников и возможно списком команд сборки), который можно было бы загрузить. У них было что-то вроде workspace, т.е. файл в котором сохранялись пути к открытым в самом редакторе файлам, это можно было сохранить и загрузить, но ведь это не совсем то - если в проекте 200 файлов, то не будешь же держать 200 открытых закладок?
Ладно меньше, но они становятся НЕЗАМЕТНЕЕ! На скриншоте из OS X полоса просто отличная - яркая, заметная, объемная. А сейчас в винде, да и во многих линуксах делают их какими-то бледными, едва различимыми на фоне окон. Или еще так: есть сама полоса прокрутки, есть фоновая область по которой полоса двигается - и зачастую фиг различишь, где полоса а где область. Чуть отличающиеся оттенки серого - и всё. Т.е. нужно задумываться, а куда собственно тыкать мышкой, чтобы попасть именно в полосу - потому что попадание в пустую область тоже приводит к прокрутке, но другого типа - листанию страниц, что не всегда нужно.
Интересно, а зачем с точки зрения дизайна языка вообще ввели отдельно null и отдельно undefined? Не проще ли было обойтись каким-то одним? Для реализации абстракции опционалов вполне достаточно одного.
В этом есть какой-то глубокий (основанный на какой-то умной околоматематической теории) смысл, или просто так сложилось/не сложилось?
А как думаете, мог бы формат TeX быть взят за основу для веб-страниц вместо html? Был бы в этом случае веб лучше или хуже чем сейчас?
Не, не секреты. Проекты простейшие. Там именно что-то с работой gradle и его файлами. И даже было такое, что компилятор или какой-то другой инструмент сборки падал на каких-то файлах (Execution failed for task ':app:processDebugMainManifest'), при этом AndroidStudio выдавала подсказки что нужно исправить. Вообще все это создает впечатление полнейшей несогласованности набора инструментов. Даже вот пункты меню типа "Sync project with Gradle files" - это вообще что? Правая рука не знает что делает левая?
Сама АндроидСтудия как IDE - просто отличная, никаких нареканий; но им бы открутить все эти сборочные поделия и написать полностью свою интегрированную в IDE инфраструктуру сборки проектов, в идеале основанную на простых "файлах проектов" (xml как в Visual Studio) без всякой императивщины (да, я считаю что любые активные скрипты в файле проекта - зло, и в 99% не нужны, достаточно просто списка файлов исходников и перечня опций компилятора, а там где нужны, должны быть огорожены специальными тегами наподобие prebuild_action / postbuild_action).
У меня есть некие собственные впечатления о разработке под андроид. Я на чем только не писал, однажды решил ради интереса попробовать и под Android. Сам язык (Java или Kotlin) никаких проблем разумеется не вызвал, после С/С++ и общих представлений о множестве других языков. А вот что не понравилось, так это тотальная зависимость Android Studio (а конкретно системы сборки Gradle) от интернета. Если интернет не совсем обычный (хитрые корпоративные политики безопасности на шлюзе) или его вообще нет, оно не работает. Если интернет есть и обычный - оно лезет туда на каждый чих и что-то скачивает. Создает какие-то кэши скачанного, которые очень быстро раздуваются до гигабайтных размеров. Это печально, коробочные продукты в которые "все включено" гораздо приятнее.
Еще: если допустим скачиваешь чей-нибудь проект с гитхаба, написанный для Visual Studio (С++, C#), или для Qt - проблем со сборкой как правило нет. Даже проекты олдскульного Visual Studio 6 1998 года конвертируются в форматы любых современных студий. Здесь же - сразу какие-то заморочки, и обычно ничего не собирается, по причинам загадочным и не имеющим отношения к синтаксическим ошибкам в коде. Т.е. программист, вместо того чтобы думать об абстракциях кода, вынужден будет заниматься каким-то шаманством непонятно с чем. Это печально, и еще раз наводит на мысли о принципиальной неправильности самой концепции "систем сборки" как таковых.
Что касается GUI, то могу только сказать - да, есть некая специфика, интуитивно она мне не очень понравилась, но я особо и не разбирался. Допускаю что все это нужно для универсального описания GUI, способного работать на произвольном размере экрана и с произвольными настройками пользователя.
И что, прямо сигнал с телефона добивает до спутника?
А внутри горизонта событий можно двигаться в произвольном направлении (в том числе и от центра черной дыры, в стороны и т.д.), или только строго к центру? Что говорит об этом математика?
Гитхаб тут недавно подложил свинью в виде обязательной двухфакторной аутентификации. Вбитые в гит ключи пока работают, а на сайт без 2FA уже не попасть:( Вот зачем оно мне, если я использую гитхаб только как хранилище личных заметок и исходников нескольких личных же утилит?
Не знаю что и делать, то ли изучать этот вопрос (как обойти минимальными затратами), то-ли отказываться от гитхаба. И отказываться не хочется, у меня были планы насчет их github.io pages...
Возможно, они бы и не справились. Все-таки накрутили в современном С++ столько, что сам черт ногу сломает. Или голову.
Очевидно что есть ПДД, которые нужно соблюдать. И если принять что техника исправна (т.е. мы исключаем фактор неисправной техники - он всегда был, и задолго до ИИ, к примеру отказали тормоза), то получается, что автопилоту точно известны места и условия, где к примеру пешеходы могут переходить дорогу, и где не могут. Поэтому если так сложилось, что пешеход выскочил ночью из леса на проезжую часть, где нет переходов и светофоров, и автопилот уже не может безопасно затормозить или изменить траекторию, то такой пешеход будет сам виноват, если его задавят. Будь он хоть трижды лауреат Нобелевской премии с тридцатью тремя детьми.
При условии стопроцентного соблюдения правил всеми участниками, и при условии исправной техники, аварии полностью исключены. Поэтому, при условии исправной техники, в любой аварии всегда виноват конкретный человек. Именно это и должно быть критерием в "проблеме вагонетки".
А в современных процессорах/материнках есть встроенные аппаратные генераторы случайных чисел? (хотя-бы на основе "теплового шума")?
Интересная и объемная статья. Когда прочитал "Лабиринт отражений" (лет 20 назад?), сразу пришла в голову мысль: а что если использовать обычный, классический гипноз для погружения человека в виртуальный мир компьютерной игры? Понятно что никаких "deep" эффектов в реальности нет, но ведь гипноз-то вполне себе есть. Кажется, даже написал автору на какой-то форум, он ведь по первой профессии психиатр, по идее это ему должно быть хоть немного знакомо.
И еще. Вот эта тема меня очень интерсует:
В детстве действительно восприятие гораздо более яркое и насыщенное. Эффект погружения практически от всего, будь то игрушки, примитивно нарисованные мультики или просто цветные камешки на земле. И вроде все об этом знают, но мне интересно - есть ли какие-то научные исследования на эту тему? Как с точки зрения науки вообще называется это детское восприятие? Можно ли его достичь во взрослом состоянии? Есть ли, к примеру, препараты, изменяющие работу мозга так, чтобы взрослый мог вернуться в это состояние? (нет, экспериментировать над собой с препаратами не планирую, но интересна любая научная информация по этой теме).
У меня в заметках числятся две вещи, которые нужно до вас донести в комментариях к первой же статье:) Вот они:
Адресная строка и punycode. Например, видим в адресной строке
https://ru.wikipedia.org/wiki/Заглавная_страница
а если скопировать это в буфер обмена и затем вставить в любой текстовый редактор, то получим там вот это
https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0
Зачем так сделано? Я часто вставляю ссылки в документы, в текстовые файлы, в исходники и в прочие места, и хочу видеть там человекочитаемый текст, а не закодированный в 6 раз длиннее. Или хотя-бы сделайте настройку, в каком виде копировать адресную строку в буфер обмена.
(я это обхожу пока так: копирую ссылку без первой буквы h, тогда она нормально копируется, а затем букву дописываю вручную)
Случайное удаление плиток с сайтами и группами со стартовой страницы. Удалить плитку очень просто случайным щелчком по "минусу" в правом верхнем углу плитки. А восстановить - невозможно (особенно если там целая папка, в которой много ссылок, это по памяти уже точно не восстановишь). Сделайте хотя-бы диалоговое окно "Вы уверены что хотите удалить?".
Список команд, но не список файлов. Geany сохраняет в своем "проекте" список файлов, открытых в редакторе, а это не то: в проекте (как абстракции разработки) запросто может быть больше файлов, чем открыто в редакторе, и в редакторе запросто могут быть открыты файлы, не относящиеся к текущему проекту.
Идея то ведь простая. Есть группа файлов (располагающихся где угодно, не обязательно в одной директории), которые я в рамках какой-то работы хочу иметь всегда под рукой в виде списка (а лучше дерева с "виртуальными" папками) в панели слева. Открывать их оттуда щелчком мыши, а при закрытии закладки с этим файлом он не должен пропадать из списка. Ровно это делается во всех IDE, в частности в Visual Studio, Qt Creator и т.д. Но в Geany этого нет, поэтому Geany все-же остается текстовым редактором, а не IDE.
А зачем "Иван Иванович", когда все уже давно придумано: "Пациент с номером 123, пройдите на прием".
Можно предложить такую формулировку: "перевести на тот язык, который будет понятен всем участникам команды". И если там есть непонятные термины предметной области, без которых никак - то их задача разжевать эти термины (в том числе уточняя у заказчиков, консультантов, в специальной литературе и т.п.) и оформить эти разъяснения документально, причем все это следует обсуждать и делать вместе с программистами.
А зачем тогда нужны все эти продакты, проджекты, менеджеры и аналитики? Кажется это их задача: выяснить чего в точности хочет заказчик, перевести эти пожелания с языка предметной области на общечеловеческий, и оформить этот перевод в виде документа - задания программисту. А программист уже переводит с общечеловеческого на язык машины/ОС/фреймворка и т.п.
Хорошая софтина. В линуксе ей пользуюсь как текстовым редактором. Но кажется, у них не было понятия "проекта" (как отдельного файла со списком файлов исходников и возможно списком команд сборки), который можно было бы загрузить. У них было что-то вроде workspace, т.е. файл в котором сохранялись пути к открытым в самом редакторе файлам, это можно было сохранить и загрузить, но ведь это не совсем то - если в проекте 200 файлов, то не будешь же держать 200 открытых закладок?
Меня пока phind.com вполне устраивает.
Ладно меньше, но они становятся НЕЗАМЕТНЕЕ! На скриншоте из OS X полоса просто отличная - яркая, заметная, объемная. А сейчас в винде, да и во многих линуксах делают их какими-то бледными, едва различимыми на фоне окон. Или еще так: есть сама полоса прокрутки, есть фоновая область по которой полоса двигается - и зачастую фиг различишь, где полоса а где область. Чуть отличающиеся оттенки серого - и всё. Т.е. нужно задумываться, а куда собственно тыкать мышкой, чтобы попасть именно в полосу - потому что попадание в пустую область тоже приводит к прокрутке, но другого типа - листанию страниц, что не всегда нужно.
Еще бы знать что такое "мощность регулярна" и "мощность сигнулярна":)