Реальных преимуществ хранения исходных кодов в бинарном виде не видно. А вот что можно было бы сделать, на мой взгляд, так это добавить в IDE возможность "на лету" применять индивидуальные для разработчика правила форматирования: пусть каждый видит то, что ему удобнее, табы, пробелы, скобки и запятые на нужной строке, комфортное количество пустых строк между методами и так далее. В таком случае исходники остаются легко читаемыми и редактируемыми в любом текстовом редакторе и в то же время в IDE каждый видит код именно с таким форматированием, к которому привык. Изменения сохранять с неким "усредненным" автоматическим форматированием.
Можно сказать что табы изначально служили именно этой идее - показывать на каждой системе индивидуально настроенное представление одного и того же текста путём задания ширины таба.
PS Комментарии типа "забей", "просто привыкни" нахожу неприемлимыми в эпоху избытка доступных вычислительных ресурсов и больших лингвистических моделей, бороздящих просторы Большого театра.
Только что разбирал старенький Dell Latitude 5580, не мог нарадоваться. Никаких ломающихся защёлок, никаких винтов с хитрым шлицем, никаких клея, скотча и компаунда - всё разбирается одной крестовой отвёрткой.
Подскажите, а чисто теоретически можно ли сделать ускоритель-гейзер из потока частиц с высокой энергией (возможно, десятки ГэВ)? Примерно как шарик, удерживаемый потоком воздуха. На высоте, где эффективность струи падает, КА включает ракетные двигатели и отделяется от стартовой платформы, принимающей на себя удары частиц. Платформа плавно опускается в место запуска на слабеющем потоке.
Ну и чтобы два раза не вставать: нейтральные частицы ускорять сложно, а заряженные будут вести себя не слишком правильно в магнитном поле Земли и атмосфере. Можно ли разгонять заряженные частицы отдельно, а потом смешивать два потока, чтобы они «рекомбинировали»?
Реальных преимуществ хранения исходных кодов в бинарном виде не видно. А вот что можно было бы сделать, на мой взгляд, так это добавить в IDE возможность "на лету" применять индивидуальные для разработчика правила форматирования: пусть каждый видит то, что ему удобнее, табы, пробелы, скобки и запятые на нужной строке, комфортное количество пустых строк между методами и так далее. В таком случае исходники остаются легко читаемыми и редактируемыми в любом текстовом редакторе и в то же время в IDE каждый видит код именно с таким форматированием, к которому привык. Изменения сохранять с неким "усредненным" автоматическим форматированием.
Можно сказать что табы изначально служили именно этой идее - показывать на каждой системе индивидуально настроенное представление одного и того же текста путём задания ширины таба.
PS Комментарии типа "забей", "просто привыкни" нахожу неприемлимыми в эпоху избытка доступных вычислительных ресурсов и больших лингвистических моделей, бороздящих просторы Большого театра.
Только что разбирал старенький Dell Latitude 5580, не мог нарадоваться. Никаких ломающихся защёлок, никаких винтов с хитрым шлицем, никаких клея, скотча и компаунда - всё разбирается одной крестовой отвёрткой.
Ну и чтобы два раза не вставать: нейтральные частицы ускорять сложно, а заряженные будут вести себя не слишком правильно в магнитном поле Земли и атмосфере. Можно ли разгонять заряженные частицы отдельно, а потом смешивать два потока, чтобы они «рекомбинировали»?