Примерная мощность излучения такого цилиндра — 373423 Вт при 20 градусах. Соответственно вода замерзнет менее чем через 7 минут, если нет других источников тепла. Если экранировать 95% этого излучения, то получим 18671 Вт, что вполне можно скомпенсировать энергетическими системами станции.
The first public preview version of AppCode became available in April 2011. 5 лет уже какбэ. Релиз 1.0 вроде в сентябре 2011 был.
С IDEA не сталкивался, но вроде многие её так же ругают за ресурсоемкость.
просто сразу предоставляется настройка кодстайла для местной ide и всё, дальше всё форматируется хоткеями
У нас тоже так, но вот новоприбывшего (несколько месяцев назад) девелопера и одного из старожилов до сих пор приходится тыкать носом на каждом код ревью. К тому же сам инструмент (clang-format) очень далек от идеала и практически не имеет настроек, что не позволяет применять его к каждой строке кода.
ну, возможно я что-то не так понял. Я понял так, что автор хочет хранить код в промежуточном виде, а отображать как душенька пожелает.
Ну это он уже немного ушел от основной идеи — хранение обычного кода на обычном ЯП в подобии AST. Как один из профитов — получаем отделение форматирования от кода. Но так как ООП языки имеют много общих парадигм, то, следовательно, одно и то же AST можно было бы транслировать (не без ограничений конечно) в разные языки.
а что за ide, если не секрет?
В мире разработки под iOS их всего две — Xcode от Apple и AppCode от Jetbrains. Первый не умеет нормальный рефакторинг, кроме самых базовых вещей, и то — очень глючно. Во втором есть мощный рефакторинг, анализатор и много чего еще, но индексирование занимает вечность.
типичные плюсовые заморочки. Если мне не изменяет память, то была какая-то программа, которая делает прекомпилированные файлы заголовков и их не надо постоянно парсить на каждый чих
Это умеет сам компилятор (например GCC). Но при сборке «начисто» все прекомпилированные заголовки создаются заново. Кроме того приходится ручками составлять .pch файл с библиотечными заголовками, чтобы ускорить компиляцию. Все это выглядит как большой костыль, чем он по сути и является.
Так дифф нужно строить по AST, а не по его представлению в хранилище. Если семантический дифф по коду вполне себе строится, то по AST этого же языка — и подавно.
Так кода ведь не меньше, просто он в другом месте (тот же индекс или парсинг AST), и в нем были, есть и будут баги. Кроме того он выполняется во время набора текста, что ничем не отличается от варианта с БД, кроме возможности объединить эти операции в одну атомарную транзакцию.
Хотя я вижу одну потенциальную проблему, — если софт работы с БД глючный, то мы можем полностью потерять доступ к коду. Текстовый файл мы в любой момент можем открыть в любом из бесчисленного количества текстовых редакторов. Если баг в парсере, то мы теряем возможность компиляции, но сам код всегда остается доступен, его можно собрать на другой машине например. В качестве решения можно предложить экспорт в виде git репозитория с обычной файловой структурой и текстовыми файлами, одним словом — бэкап.
Разным людям нравится разное форматирование кода (а еще — разные инструменты/IDE/ОС/ноутбуки).
Банально — непривычно форматированный код читать сложнее, уходит время, чтоб натренировать глаз. Новонабранная команда будет неделю холиварить по поводу табов/пробелов в новом проекте. Это все не выдумки, а реальные проблемы.
Почему бы не дать возможность сделать форматирование индивидуальным, как цветовую схему редактора?
Снова недостатья с копипастой описания продуктов. А в чем преимущество каждого конкретного продукта перед email? Как организовать тот или иной инструмент для адекватной замены электронной почте?
Ну БД по сути и есть индекс. Механизмы работы с БД также хорошо отлажены за много лет.
1) Сохранение
Сейчас многие редакторы не требуют сохранения, оно перманентно, Ctrl/Cmd+S — устаревшая парадигма, от которой пытаются уйти.
2) Ввод и визуализация
Все точно так же, как и сейчас, но вместо файла — открываем класс или, возможно, модуль.
3) Индексация (в т.ч. анализ и рефакторинг)
Все точно как сейчас, просто меняем парсинг и работу с индексом на запрос к БД.
4) Версионирование (+ обмен изменениями с коллегами)
Вот тут проблема, так как использовать существующие VCS, работающие с текстовыми файлами, — невозможно.
Нужна имплементация на уровне БД. Для гитхаба можно было бы делать экспорт в git.
> как много потратится время на нажатие твоего любимого хоткея в IDE для выправления кодстайла? меньше секунды на нажатие alt+shift+f
Дело не во времени, а в удобочитаемости и привычке. При смене места работы/команды/проекта приходится придерживаться нового стиля, это раздражает и добавляет проблем в виде разногласий с другими членами команды и ухудшению продуктивности.
> и тут мы пришли к уже существующим .obj или .coff или .class файлам
Это все же про другое, некий промежуточный универсальный язык, байткод. Если я правильно понимаю автора, то речь идет о возможности хранения кода, например С/С++, в виде синтаксического дерева в некоторой БД. Каждый программист может сам выбирать правила форматирования отображаемого кода. Многие уже сейчас строят костыли в виде скриптов, которые переформатируют код перед каждым коммитом/пушем в git.
> это уже сделано и прекрасно работает
Что работает? Аннотации в Java? Работают, но это не значит, что можно сделать лучше.
> всё уже давно сделано и изобретено, у всякой уважаемой себя ide есть вот это всё
А если конкретно в моей нет или оно страшно глючное? Кстати в альтернативных IDE — немногим лучше.
> особенно клёво когда компилируется прямо во время написания кода
Ну вот clang например каждый раз парсит DSL для каждого отдельного файла, подтягивая всю цепочку импортировнных заголовков. Как по мне — это пустая трата ресурсов.
Удивляет, что такой консервативный комментарий набирает столько плюсов.
А меня вот бесит постоянно отваливающийся индекс в IDE и то, что его постройка занимает иногда весьма внушительное время.
Опять же, в чем разница — открыть нужный файл, или открыть нужный класс из БД. Я был бы рад не заморачиваться созданием нового файла на каждый класс, класть его в свой каталог, как-то называть. Мне ведь нужен класс, а не файл, и было бы круто, если бы я мог его создать в неком общем репозитории, а при необходимости — экспортировать в текстовом виде или в той же БД.
Вот наличие обширной инфраструктуры — это большой плюс текстовых файлов, но это никак не может быть стопором для альтернативных подходов. Вполне можно объединять две парадигмы в одном проекте, как совмещают несколько языков программирования.
Эта тема кстати близка теме поиска альтернативы устаревающей парадигме файловой системы. Некоторые новые ОС уже копают в данном направлении.
Аналогичные мысли посещают меня уже пару лет. Предложить альтернативу — достаточно сложно. Инициатором по хорошему должен быть разработчик одной из популярных IDE. Так как внедрить в существующие IDE (для меня Xcode) новый формат хранения кода, да еще и с поддержкой компилятора, системы контроля версий, довольно сложно, если не невозможно (на должном уровне). Единственное — можно написать конвертер текстновый формат, и надеятся, что разработчики IDE его подхватят.
Это примерно как с HTML, никто не предполагал делать на нем то, что делают сейчас, но и альтернатив нет, а предлагать их должны не разработчики сайтов, но разработчики браузеров.
А что с силой тока? В теории электрических цепей есть абстракции идеальных источников напряжения и тока. Так вот, для идеального источника напряжения мы получим бесконечно большой ток при нулевом сопротивлении. А для идеального источника тока — бесконечно большое напряжение при нулевой проводимости цепи. Так что в этой теории сингулярности вполне себе присутствуют.
Вы описали то же самое, но другими словами. В первом случае мы меняем условия поэтапно, во втором — проверяем выживаемость на разной территории (поэтапно). Второй случай лучше ложится в классическое описание ГА с одно фитнесс функцией, но на любой алгоритм можно найти другой, эквивалентный ему. Разумеется предпочтение отдается наиболее эффективному.
> если в первом случае хоть как-то присутствует возможность линейного наращивания решения с планомерными приближением к эталонному результату, то в случае с сортировками, алгоритмы с единственным неверным шагом коверкают результат до неузнаваемости.
Как в таких условиях адекватно оценить, насколько хорошо претендент прошел испытание? У меня нет ответа. Как выбрать из двух претендентов, если они одинаково не отсортировали массив, но за разное количество выполненных команд?
Можно не пытаться скармливать сразу большой массив и как-то анализировать пригодность результата. Эволюция же работает с малыми изменениями окружающей среды, при радикальных изменениях она терпит крах (массовые вымирания видов).
Предлагаю выращивать популяцию, способную сортировать короткие массивы, начиная например с 3 элементов.
Имея такую популяцию уже можно вносить изменения в окружение — увеличить размер массива на один элемент.
Те, кто справился, — проходят без изменений. Остальные мутируют/скрещиваются, пытаются адаптироваться.
Увеличение длины массива можно рассматривать как распространение вида на новые территории. Более универсальный вид захватит максимально возможную территорию (как это сделал, к примеру, человек).
Интересно то, что о «концевом эффекте» было известно до катастрофы. Но, видимо, никто не додумался просчитать его величину при малом запасе реактивности.
Странным выглядит и решение сделать графитовые вытеснители на 2 метра короче активной зоны, сознательно внося неоднородность в активную зону. Получается о «концевом эффекте» должно было быть известно еще на этапе проектирования. Возможно отрасль была молодая, и квалификация рецензентов не позволила выявить критический недостаток.
Но высота активной зоны РБМК-100 тоже не 20 метров (очевидно некоторые источники врут), а 7.
Тогда 7м / 0,4м/с = 17.5 с, что близко к 18...20с, указанных Дятловым (0,4м/с — средняя скорость).
С IDEA не сталкивался, но вроде многие её так же ругают за ресурсоемкость.
У нас тоже так, но вот новоприбывшего (несколько месяцев назад) девелопера и одного из старожилов до сих пор приходится тыкать носом на каждом код ревью. К тому же сам инструмент (clang-format) очень далек от идеала и практически не имеет настроек, что не позволяет применять его к каждой строке кода.
Ну это он уже немного ушел от основной идеи — хранение обычного кода на обычном ЯП в подобии AST. Как один из профитов — получаем отделение форматирования от кода. Но так как ООП языки имеют много общих парадигм, то, следовательно, одно и то же AST можно было бы транслировать (не без ограничений конечно) в разные языки.
В мире разработки под iOS их всего две — Xcode от Apple и AppCode от Jetbrains. Первый не умеет нормальный рефакторинг, кроме самых базовых вещей, и то — очень глючно. Во втором есть мощный рефакторинг, анализатор и много чего еще, но индексирование занимает вечность.
Это умеет сам компилятор (например GCC). Но при сборке «начисто» все прекомпилированные заголовки создаются заново. Кроме того приходится ручками составлять .pch файл с библиотечными заголовками, чтобы ускорить компиляцию. Все это выглядит как большой костыль, чем он по сути и является.
Хотя я вижу одну потенциальную проблему, — если софт работы с БД глючный, то мы можем полностью потерять доступ к коду. Текстовый файл мы в любой момент можем открыть в любом из бесчисленного количества текстовых редакторов. Если баг в парсере, то мы теряем возможность компиляции, но сам код всегда остается доступен, его можно собрать на другой машине например. В качестве решения можно предложить экспорт в виде git репозитория с обычной файловой структурой и текстовыми файлами, одним словом — бэкап.
Разным людям нравится разное форматирование кода (а еще — разные инструменты/IDE/ОС/ноутбуки).
Банально — непривычно форматированный код читать сложнее, уходит время, чтоб натренировать глаз. Новонабранная команда будет неделю холиварить по поводу табов/пробелов в новом проекте. Это все не выдумки, а реальные проблемы.
Почему бы не дать возможность сделать форматирование индивидуальным, как цветовую схему редактора?
Сейчас многие редакторы не требуют сохранения, оно перманентно, Ctrl/Cmd+S — устаревшая парадигма, от которой пытаются уйти.
Все точно так же, как и сейчас, но вместо файла — открываем класс или, возможно, модуль.
Все точно как сейчас, просто меняем парсинг и работу с индексом на запрос к БД.
Вот тут проблема, так как использовать существующие VCS, работающие с текстовыми файлами, — невозможно.
Нужна имплементация на уровне БД. Для гитхаба можно было бы делать экспорт в git.
Дело не во времени, а в удобочитаемости и привычке. При смене места работы/команды/проекта приходится придерживаться нового стиля, это раздражает и добавляет проблем в виде разногласий с другими членами команды и ухудшению продуктивности.
> и тут мы пришли к уже существующим .obj или .coff или .class файлам
Это все же про другое, некий промежуточный универсальный язык, байткод. Если я правильно понимаю автора, то речь идет о возможности хранения кода, например С/С++, в виде синтаксического дерева в некоторой БД. Каждый программист может сам выбирать правила форматирования отображаемого кода. Многие уже сейчас строят костыли в виде скриптов, которые переформатируют код перед каждым коммитом/пушем в git.
> это уже сделано и прекрасно работает
Что работает? Аннотации в Java? Работают, но это не значит, что можно сделать лучше.
> всё уже давно сделано и изобретено, у всякой уважаемой себя ide есть вот это всё
А если конкретно в моей нет или оно страшно глючное? Кстати в альтернативных IDE — немногим лучше.
> особенно клёво когда компилируется прямо во время написания кода
Ну вот clang например каждый раз парсит DSL для каждого отдельного файла, подтягивая всю цепочку импортировнных заголовков. Как по мне — это пустая трата ресурсов.
Удивляет, что такой консервативный комментарий набирает столько плюсов.
Опять же, в чем разница — открыть нужный файл, или открыть нужный класс из БД. Я был бы рад не заморачиваться созданием нового файла на каждый класс, класть его в свой каталог, как-то называть. Мне ведь нужен класс, а не файл, и было бы круто, если бы я мог его создать в неком общем репозитории, а при необходимости — экспортировать в текстовом виде или в той же БД.
Вот наличие обширной инфраструктуры — это большой плюс текстовых файлов, но это никак не может быть стопором для альтернативных подходов. Вполне можно объединять две парадигмы в одном проекте, как совмещают несколько языков программирования.
Эта тема кстати близка теме поиска альтернативы устаревающей парадигме файловой системы. Некоторые новые ОС уже копают в данном направлении.
Это примерно как с HTML, никто не предполагал делать на нем то, что делают сейчас, но и альтернатив нет, а предлагать их должны не разработчики сайтов, но разработчики браузеров.
Как в таких условиях адекватно оценить, насколько хорошо претендент прошел испытание? У меня нет ответа. Как выбрать из двух претендентов, если они одинаково не отсортировали массив, но за разное количество выполненных команд?
Можно не пытаться скармливать сразу большой массив и как-то анализировать пригодность результата. Эволюция же работает с малыми изменениями окружающей среды, при радикальных изменениях она терпит крах (массовые вымирания видов).
Предлагаю выращивать популяцию, способную сортировать короткие массивы, начиная например с 3 элементов.
Имея такую популяцию уже можно вносить изменения в окружение — увеличить размер массива на один элемент.
Те, кто справился, — проходят без изменений. Остальные мутируют/скрещиваются, пытаются адаптироваться.
Увеличение длины массива можно рассматривать как распространение вида на новые территории. Более универсальный вид захватит максимально возможную территорию (как это сделал, к примеру, человек).
Странным выглядит и решение сделать графитовые вытеснители на 2 метра короче активной зоны, сознательно внося неоднородность в активную зону. Получается о «концевом эффекте» должно было быть известно еще на этапе проектирования. Возможно отрасль была молодая, и квалификация рецензентов не позволила выявить критический недостаток.
Тогда 7м / 0,4м/с = 17.5 с, что близко к 18...20с, указанных Дятловым (0,4м/с — средняя скорость).