Неоднократно встречал в литературе упоминания о том, что в некоторых средах разработки
тексты программ могут храниться и использоваться не в виде файлов. А где они тогда хранятся и
как компилируются ? И вообще, это что — чисто академические "трюки" какой-нибудь группы
профессоров или реально применяемая технология ?
23.07.10 15:17: Перенесено модератором из 'C/C++. Прикладные вопросы' — Кодт
Здравствуйте, okman, Вы писали:
O>Привет всем !
O>Неоднократно встречал в литературе упоминания о том, что в некоторых средах разработки O>тексты программ могут храниться и использоваться не в виде файлов. А где они тогда хранятся и O>как компилируются ? И вообще, это что — чисто академические "трюки" какой-нибудь группы O>профессоров или реально применяемая технология ?
Очень много простора для фантазии оставляете...
В книге любой исходники возьмите — хранятся? — хранятся! в виде файлов? — нет, в виде печатного текста.
С другой стороны ничего не мешает держать исходники в некотором участке оперативной памяти и скармливать их как поток в лексический анализатор (на первую стадию компиляции)
Здравствуйте, BogusCoder, Вы писали:
BC>Здравствуйте, okman, Вы писали:
BC>С другой стороны ничего не мешает держать исходники в некотором участке оперативной памяти BC>и скармливать их как поток в лексический анализатор (на первую стадию компиляции)
в оперативной памяти их можно хранить разве что в кластере, где отказ одной машин (пререзагрузка, зависание, сбой по питанию) не приведет к необратимой утере данных. но даже в оперативной памяти очень сложно без концепции файла.
я могу себе представить IDE, хранящую исходники в базе данных, которая в свою очередь хранится на диске в "сыром" виде (т.е. без файловой системы), то если вспомнить, что файловая система это по сути база данных, то мне будет не понять, чем радикально хранение исходных текстов в SQL будет отличаться от хранения их на диске. ну разве что для мелких файлов SQL будет быстрее. можно помещать тело каждой функции в базу, но! по сути библиотекари (те которые в си создают Lib файлы) почти так и работают, пихая кучу obj в один lib.
все-таки, что такое файл? ведь даже экран монитора это файл. ну в некотором смысле. а потому без четкого определения что понимать под файлом спорить нет смысла.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, okman, Вы писали:
O>Неоднократно встречал в литературе упоминания о том, что в некоторых средах разработки O>тексты программ могут храниться и использоваться не в виде файлов. А где они тогда хранятся и O>как компилируются ? И вообще, это что — чисто академические "трюки" какой-нибудь группы O>профессоров или реально применяемая технология ?
Например, насколько я помню, VisualAge в этом плане отличается:
I ran hard into the philosophical disjunction between VisualAge and every coding methodology I’ve ever used and wasn’t able to reconcile it. VisualAge doesn’t use the file system of your computer to store its projects (or your code!). Instead, it stores all the source and object code away inside a repository into which you must check classes into and out. If you want to work on an existing project, you must first import the entire codebase and any supporting classes you need into the VisualAge repository.
Здравствуйте, okman, Вы писали:
O>Неоднократно встречал в литературе упоминания о том, что в некоторых средах разработки O>тексты программ могут храниться и использоваться не в виде файлов. А где они тогда хранятся и O>как компилируются ? И вообще, это что — чисто академические "трюки" какой-нибудь группы O>профессоров или реально применяемая технология ?
Ну вообще-то такое было ещё в старых Бейсиках 16-битных персоналок. Программа в памяти хранилась в распарсенном виде. Простейший вариант экономии — замена всяких LET, GOTO на однобайтные значения, сжатие числовых констант.
По команде сохранения в файл коды операторов заменялись на слова. В некоторых можно было выгружать в файл в сжатом виде и быстро загружать оттуда без парсинга.
Позднее я про такое не слышал — потому что системы контроля версий могут нервно реагировать на результат парсинга и обратного вывода (даже если изменение в количестве пробелов), а они в этом смысле сейчас главнее IDE
Хотя вполне можно уже думать и про хранение в сжатом виде или канонической форме.
Ну как я себе представляю — компьютер, где обращения определенных программ к файловой системе
транслируются, к примеру, в обращения к базе данных или физической памяти очень большого объема.
Соответственно, удобство хранения, выигрыш в скорости компиляции и другие плюсы.
Упоминаются эти вещи в основном вскользь, потому и интересуюсь. Может, кто-то работал с такими системами...
Здравствуйте, okman, Вы писали:
O>Неоднократно встречал в литературе упоминания о том, что в некоторых средах разработки O>тексты программ могут храниться и использоваться не в виде файлов. А где они тогда хранятся и O>как компилируются ? И вообще, это что — чисто академические "трюки" какой-нибудь группы O>профессоров или реально применяемая технология ?
А вот была такая хорошая платформа PalmOS. Там вообще понятия "файл" не было, хотя было во многом сходное понятие "база данных". И был для этой платформы нативный компилятор языка C, OnBoardC. Этот компилятор брал исходники из баз данных текстового редактора. Плюс, у него в комплекте была своя база данных с предобрадотанными заголовками от SDK (чтобы места поменьше занимали).
В FoxPro (это из относительно недавнего) исходники классов и необходимые им ресурсы и формы хранились в БД, компилировались туда же. Это чтобы системы контроля версий подавились наверное. В редакторе они подавались пометодно, то еще удобство.
Совсем давно приходилось сталкиваться с неким Sybase Designer или Developer (уже и не припомню точно). Тоже все в БД, но основной "импрувмент" был в том, что программа рисовалась исключительно мышкой, весь контекст и конструкции предоставлялись на тулбарах и перемещались исключительно мышой, клавиатура требовалась только для обзывания идентификаторов. Т.е. вроде перед тобой и код, но текстового курсора, как такового, нет.
Еще забыл, сибэйзовская прога позволяла работать команде над одним проектом в реалтайм. Все пишут в одну базу, локи на модифицируемый метод, отладка всегда последней версии, грубых ошибок там в принципе допустить невозможно. Для начала 90-х было крайне необычно. Дельфи и жавы тогда еще не было совсем.
Могут. Их, исходников, может вообще не быть. Мало того и программы, как таковой, может не быть.
И все это не чисто академические "трюки" какой-нибудь группы профессоров, а реально применяемая технология.
Я говорю о технологии Флора, разрабатываемой фирмой Компас Плюс.
Этой технологии уже лет 15. Несколько лет назад я вел бурную деятельность по продвижению Флоры, но ничего не вышло. Жаль конечно.
В новой технологии фирмы — Radix исходники тоже хранятся не в файлах.
Если будет интерес, могу рассказать подробнее.
Здравствуйте, netch80, Вы писали:
N>Ну вообще-то такое было ещё в старых Бейсиках 16-битных персоналок. Программа в памяти хранилась в распарсенном виде. Простейший вариант экономии — замена всяких LET, GOTO на однобайтные значения, сжатие числовых констант. N>По команде сохранения в файл коды операторов заменялись на слова. В некоторых можно было выгружать в файл в сжатом виде и быстро загружать оттуда без парсинга.
В Smalltalk и сейчас так все и хранится.
N>Позднее я про такое не слышал — потому что системы контроля версий могут нервно реагировать на результат парсинга и обратного вывода (даже если изменение в количестве пробелов), а они в этом смысле сейчас главнее IDE N>Хотя вполне можно уже думать и про хранение в сжатом виде или канонической форме.
Ну ничто ни мешает сделать системы контроля версий работающие не с текстом а с внутренним представлением (AST или т. п.) В тех Smalltalk системах свои VCS есть.
Здравствуйте, Lever, Вы писали:
L>Могут. Их, исходников, может вообще не быть. Мало того и программы, как таковой, может не быть. L>И все это не чисто академические "трюки" какой-нибудь группы профессоров, а реально применяемая технология. L>Я говорю о технологии Флора, разрабатываемой фирмой Компас Плюс. L>Этой технологии уже лет 15. Несколько лет назад я вел бурную деятельность по продвижению Флоры, но ничего не вышло. Жаль конечно. L>В новой технологии фирмы — Radix исходники тоже хранятся не в файлах. L>Если будет интерес, могу рассказать подробнее.
Здравствуйте, dimok@, Вы писали:
D>В FoxPro (это из относительно недавнего) исходники классов и необходимые им ресурсы и формы хранились в БД, компилировались туда же. Это чтобы системы контроля версий подавились наверное. В редакторе они подавались пометодно, то еще удобство.
Угу. Но при этом из FoxPro можно было сделать экспорт в чисто текстовом виде и уже результат экспорта обрабатывать обычными средствами. Правда, нормальных средств у нас тогда не было — даже несчастного RCS не было. Но cmp был:)
А вот довелось поработать с Access в котором такого экспорта не было — и я его возненавидел.
Здравствуйте, pro-nov, Вы писали:
PN>файлы — мертвы. мертвы не потому что используются. мертвы концептуально. как убогая пародия на объект.
Это объекты безобразно растолстевшие абстрактные типы данных. Для файлов АТД более чем достаточно.
PN>исходники это объект. их представление в файле — это вынужденная мера существования в мире морально устаревших операционных систем.
Объекты тоже того стремительно морально устаревают
Исходники точно не объект, скорее функциональный поток.
Здравствуйте, okman, Вы писали:
O>Неоднократно встречал в литературе упоминания о том, что в некоторых средах разработки O>тексты программ могут храниться и использоваться не в виде файлов. А где они тогда хранятся и O>как компилируются ? И вообще, это что — чисто академические "трюки" какой-нибудь группы O>профессоров или реально применяемая технология ?
В Smalltolk-е исходников как таковых вообще нет. Концептуально, код сразу преобразуется в байткод и помещается в "образ". Если человеку требуется код, то он добывается из образа. На практике, конечно, реализации могут поступать по разному, но человек в Smalltolk с файлами не работает.
У этой концепции есть еще одно необычное свойство. Программы Smalltolk-а думают будто бы они вечные (т.е. с точки зрения программы он никогда не выгружается). Происходит это потому, что кроме кода в образах хранятся и текущие данные (данные экземпляров объектов). Когда система останавливается она сериализует состояния объектов и помещает их в образ. Когда она стартует, то воссоздает весь граф объектов.
Концепция очень старая и очень интересная. У нее есть масса интересных приемуществ, так же как и масса несомненных недостатков. По любому с ней стоит познакомиться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, okman, Вы писали:
O>Неоднократно встречал в литературе упоминания о том, что в некоторых средах разработки O>тексты программ могут храниться и использоваться не в виде файлов. А где они тогда хранятся и O>как компилируются ? И вообще, это что — чисто академические "трюки" какой-нибудь группы O>профессоров или реально применяемая технология ?
Исходники не являются файлами очень часто, гораздо чаще, чем может показаться на первый взгляд. Причем не в экзотических продуктах, а в очень даже распространенных.
Например, в любой современной СУБД хранимые процедуры и триггеры хранятся внутри базы данных. Причем многие СУБД при этом позволяют писать хранимые процедуры и триггеры не только на соответствующем диалекте SQL, но и на JAVA, на .NET-языках, на PERL и т.д.
В Microsoft Access в базе данных хранится вся программа, включая формы, модули, запросы SQL и пр.
В любом продукте из состава Microsoft Office код на VBA и экранные формы хранятся в документе (файл формата Compound File).
Это — если рассматривать именно схему хранения исходников.
Есть еще довольно много сред программирования, где исходники хранятся в файлах, но не в текстовом виде. Примеры разных времен: Centura/Gupta, PowerDesigner, QBasic, Intermec PictoRL и т.п.