OberonCore https://forum.oberoncore.ru/ |
|
Обсуждение проекта PureBuilder https://forum.oberoncore.ru/viewtopic.php?f=93&t=3133 |
Страница 2 из 7 |
Автор: | Валерий Лаптев [ Понедельник, 10 Январь, 2011 00:15 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Сергей Прохоренко писал(а): Alexey Veselovsky писал(а): Какой-то план работ (roadmap) с ориетировочными сроками существует? У меня - нет. У Валерия Лаптева, который разрабатывает семантический редактор с близкой идеологией - наверное. Насколько я знаю, его студент, участвующий в разработке семантического редактора, должен через несколько лет защитить диплом по этой теме. Он уже на 4 курсе и принес мне первую рабочую версию - на неделе будем смотреть и копать. Основные особенности - язык программирования минимальный и русский. С учетом изысканий, которые по форме цикла Дейкстры мы тут однажды провели. Модули есть. Текст набирается сразу конструкциями. Покажу ему страничку PureBuilder - обсудим. Единственный пока минус - реализовано на Додиезе в VS 2010/ Просто они сейчас это изучают по одной дисциплине, и у него все " в пальцах". Ничего, потом перепишем. |
Автор: | Peter Almazov [ Понедельник, 10 Январь, 2011 00:17 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Илья Ермаков писал(а): MS Access и мышь - ужасные воспоминания. Я вообще с "обычными" БД работаю редко, но недавно и с Access пришлось, и с MySQL. От SQL и написания SQL-запросов, как и раньше, куча позитивных впечатлений. Access с его тыканием - ужасно. В MS Access очень хороший построитель запросов. Позитивные впечатления от написания руками получите, когда потребуется быстренько написать 5-10 запросов, в каждом из которых связано штук по 5 таблиц (примитив, на самом деле). Потом понять, что результат (полученные данные) не устраивает и быстренько все переделать.
|
Автор: | Сергей Прохоренко [ Понедельник, 10 Январь, 2011 00:30 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Валерий Лаптев писал(а): Сергей Прохоренко писал(а): Alexey Veselovsky писал(а): Какой-то план работ (roadmap) с ориетировочными сроками существует? У меня - нет. У Валерия Лаптева, который разрабатывает семантический редактор с близкой идеологией - наверное. Насколько я знаю, его студент, участвующий в разработке семантического редактора, должен через несколько лет защитить диплом по этой теме. Он уже на 4 курсе и принес мне первую рабочую версию - на неделе будем смотреть и копать. Основные особенности - язык программирования минимальный и русский. С учетом изысканий, которые по форме цикла Дейкстры мы тут однажды провели. Модули есть. Текст набирается сразу конструкциями. Покажу ему страничку PureBuilder - обсудим. Единственный пока минус - реализовано на Додиезе в VS 2010/ Просто они сейчас это изучают по одной дисциплине, и у него все " в пальцах". Ничего, потом перепишем. Это просто замечательно! Додиез - может быть, даже и плюс - на нем может получиться привлекательный интерфейс. |
Автор: | Geniepro [ Понедельник, 10 Январь, 2011 01:43 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Цитата: Лучшим кандадатом на роль встроенной СУБД является Firebird. Ашипка в слове "кандидатом". Кстати, а Sqlite рассматривали? Проще, компактнее и наверняка намного надёжнее, чем Firebird. |
Автор: | Владислав Жаринов [ Понедельник, 10 Январь, 2011 05:11 ] |
Заголовок сообщения: | О содержании визуальности представления знаний |
Драконограф писал(а): Сергей Прохоренко писал(а): Драконограф писал(а): Пока основной вопрос к понятию "визуальный" в контексте данного проекта. У UML, Дракона, блок-схем и других графов нет монополии на термин "визуальный"... Но есть и гораздо более близкая аналогия. Поиск картинок в Гугле по строке "визуальное программирование" дает несколько "неграфовых" систем программирования, в которых программа, как и в PureBuilder, собирается мышкой из "визуальных" блоков, а не набирается на клавиатуре...[/url]. В отличие от графов блоки в этих системах программирования не расползаются по экрану, а располагаются в одну вертикальную линию, как текст программы. Но это не текст... По поводу систем указанного рода - высказывался здесь о гарантоспособности.
* внутренней форме - как изделие устроено. А главное - что в этих средах код-то всё равно будет представлен текстом... И здесь переходим к "визуальным" методологиям формализации знаний о задачах - где внутреннему устройству решения (в частном случае - инфопрогизделия) найдена форма представления, отличная от текста, пусть и интендованного. Почему о некоторых средах я высказывался как об "игровых", а не профессиональных? Потому, что переход от текста к таблицам/графике как основе представления - не самоцель, а средство иначе, нагляднее отразить устройство изделия - как и в случае материальных объектов (визуализируемых по ЕСКД). А архитектура в "игровых" подходах адекватно не отражается. В HiAsm какая-то попытка сделана в стиле IDEF0 ("ICOM-изация" сторон блока) - но это и мало, и не совсем то, что мне бы, например, как независимому от программиста участнику процесса позволило бы понять логику построения изделия. Особенно с учётом сложности принципов, напр. компонентного программирования на тех же Оберон-языках - о чём говорил Илья, допустим, в связи с процедурами-объектами. А причина-то в том, что хотели всё отчуждаемое знание о программном решении задачи "впихнуть" в один тип схем... В общем, как и в ЕСКД, нужна система взаимосвязанных типов схем разного назначения - каковы они для описания матобъектов, см. напоминание в этом пункте. И о некоторых аспектах дискуссии по ДРАКОНу. Можно каждый или отдельные типы схем информатических изделий превратить из графового в табличный - но делать это нужно взвешенно, не ухудшая когнитивной эргономики. Безусловно, "красной нитью" в МФЗ должна проходить возможность декомпозиции - чтобы большое представить системами малых. Для графовой основы я предлагаю областную декомпозицию, введённую здесь, развитую здесь и показанную, в частности, на этом примере. Как сделать эквивалентно, отказываясь от графовой основы - пусть предложат сторонники отказа... |
Автор: | Владислав Жаринов [ Понедельник, 10 Январь, 2011 09:05 ] |
Заголовок сообщения: | О формах структурированного представления знаний |
Вот в тему оказалась книжка, вложенная в это сообщение. Можно отражать импер-структуры как структурограммы - т.е. фактически таблицы специального рода - тем самым достигая предлагаемого Сергеем "устранения соединительных линий" (на то же обращал внимание Илья, скажем, в упомянутых здесь сообщениях). Поскольку я не "безусловный поклонник" тех или иных средств - ничего неправильного в этом не вижу - только в тех случаях, когда этим линиям (т.е. связям) не приписаны некие значения в рамках данного рода моделей. Иначе связи надо сохранять и искать им какое-то представление в составе таблиц - что не слишком-то эргономично будет... проще тогда от графа не уходить. Но нужно учесть аспект восприятия - разные структуры следует таблично организовать по-разному (без употребления для этой цели ключевых слов - только конфигурацией и расчерчиванием ячеек). Чтобы не плодить много разновидностей ячеек и ячеечных структур - ограничить типологию представляемых прогтекстовых конструкций. В частности, для импер-структур - свести разнообразие циклов к ПОКА (и развивающему его циклу Дейкстры, конечно). Нужно что-то делать и с исключениями - имея в виду, что это "потенциально досрочные окончания" маршрутной структуры... или такая трактовка (в структурном смысле) требует уточнения? В принципе было бы интересно видеть "таблично-базированную" среду, наследующую идеи шампур-метода. Нужно только решить опять-таки с табличным представлением силуэтов... Тогда на такое представление в принципе можно перевести и ПК-, и ДМ-схемы из графит-базиса, представленного здесь - да и любые аналогичные. |
Автор: | Валерий Лаптев [ Понедельник, 10 Январь, 2011 11:27 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Кстати, мы рассматриваем Дракон в качестве основного кандидата для изображения алгоритмов при обучении начинающих. Даже в программе дисциплины явно написали. При развитии обучающей среды ОБЯЗАТЕЛЬНО включим что-нить на тему дракона в нее. |
Автор: | Владислав Жаринов [ Понедельник, 10 Январь, 2011 17:28 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Сергей Прохоренко писал(а): Peter Almazov писал(а): Вот маленькая (на фоне остальных) проблема - как должно выглядеть сравнение двух похожих версий программы? Небольшое различие в тексте может приводить к большим различиям в графическом представлении. Мне кажется, что хорошего красивого решения этой проблемы не придумать. Но сколько-нибудь приемлемое решение найти можно. Например, удаленные, модифицированные и новые элементы могут выделяться соответствующими цветами. Щелкнув по модифицированному элементу, можно посмотреть, что же изменилось в его структуре. |
Автор: | Владислав Жаринов [ Понедельник, 10 Январь, 2011 18:01 ] |
Заголовок сообщения: | О целях и средствах формализации |
Сергей Прохоренко писал(а): Кирилл Осенков, разработавший структурный редактор C#, идеологически похожий на PureBuilder, - сотрудник Microsoft (правда, структурный редактор C# - его личная инициатива). Значит, внутри "индустриальных китов" есть люди, которые понимают, что структурный редактор необходим. И не пройдет и ...дцати лет, как он станет составной частью Visual Studio. Но больно уж долго "индустриальные киты" запрягают - выжидают, пока приносят прибыль прежние разработки. И как составная часть он войдёт неизвестно в каком виде... а люди, конечно, везде есть Сергей Прохоренко писал(а): Драконограф писал(а): Для кого делается эта среда? Если "для программистов" - то тут уже поднаторели "индустриальные киты" типа MS, известные "магнаты сложности" (часто "избыточной"). Нужно ли их "переплёвывать"? А если от этого уходить, то вылезает главное - есть ББ с его концепцией "текст как интерфейс" - которой трудно противопоставть что-то Почему концепции "текст как интерфейс" трудно что-то противопоставить? Вовсе нет. Вот Вы же противопоставляете Дракон! Конкретно - цитата про "текст как интерфейс" оборвана так, что искажается смысл. Полностью фраза такова: Цитата: А если от этого уходить, то вылезает главное - есть ББ с его концепцией "текст как интерфейс" - которой трудно противопоставть что-то, если уходить от явного нетекстового представления структуры знания о задаче (да и надо ли?). Вы предлагаете как раз уходить - т.е. остаться в текстовом представлении (пусть с "расцветкой" синтаксиса) - и тут общее поле с ББ. Это я и имел в виду. ДРАКОН же (а точнее - шампур-метод и графит-метод как его развитие) находятся в другом поле - где мы уходим от чисто текстового представления знаний к "графитному". Это не противопоставление ББ - в явном смысле, на общем поле. И обратите внимание - я со сторонниками ББ не спорю - потому что против "текста как интерфейса" ничего не имею - как формы, ориентированной на определённые типы восприятия и оперирования в уме.
А в оперировании два типа: "живописцы" (по-научному "эйдетики", помнится) - представляют/преобразуют как образы; "литераторы" - то же самое как тексты. И вообще что спорить - когда, возможно, писать нормальный структурный редактор в ББ нужно будет в итоге - с учётом сказанного в этом соообщении. Как говорится, "не плюй в колодец - пригодится воды напиться" Сергей Прохоренко в viewtopic.php?p=57231#p57231 писал(а): Целевых групп PureBuilder несколько: И ещё раз - документ среды должен отражать не только текст программы - а вообще поддающееся формализации знание о решаемой задаче (конечно, это частное назначение - содержанием документа м.б. и комплекс задач, и просто комплекс сведений о "предметке", выбранных сочинителем). Т.е. он создаётся всеми участниками триады "предметник-аналитик-программист". И его содержание - это прежде всего "паспорт" задачи (её "внешняя схема"). А уж далее идёт "нейтральная" - модель, пригодная для трансляции (но прежде - для инжпроработки) - и на соответствующем языковом семействе. Причём до программирования очередь может дойти далеко не сразу - "нейтральная" формализация нужна и для инженерного анализа деятельности... А когда дойдёт - то должна получиться система взаимодействующих процессов, реализованных как инфопрог[и] и как инструкция оператору по работе с исполнителем этого инфопрога - как в этом примере.
А среди выделенных Вами целевых групп вижу снова программистов - вторая относится к "утилитаристам" (создателям изделий "для себя"), что сути дела не меняет. Если позиционировать среду как инструмент, поддерживающий гарантоспособный труд (эффективный и надёжный) - то этого недостаточно. |
Автор: | Владислав Жаринов [ Понедельник, 10 Январь, 2011 19:45 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Валерий Лаптев писал(а): Кстати, мы рассматриваем Дракон в качестве основного кандидата для изображения алгоритмов при обучении начинающих. Даже в программе дисциплины явно написали. При развитии обучающей среды ОБЯЗАТЕЛЬНО включим что-нить на тему дракона в нее. А как Вы относитесь к табличному представлению структуры - типа структурограмм?
|
Автор: | Сергей Прохоренко [ Понедельник, 10 Январь, 2011 20:38 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Geniepro писал(а): Цитата: Лучшим кандадатом на роль встроенной СУБД является Firebird. Ашипка в слове "кандидатом". Кстати, а Sqlite рассматривали? Проще, компактнее и наверняка намного надёжнее, чем Firebird. Спасибо, исправил. Рассматривал. И мы с Вами это уже обсуждали. Firebird победил. Подробности уже не помню. Помню только, что Firebird мгновенно восстанавливается после машинных сбоев. Но в любом случае выбор за Валерием Лаптевым - ему решать. |
Автор: | Сергей Прохоренко [ Понедельник, 10 Январь, 2011 21:31 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Драконограф писал(а): Вы предлагаете как раз уходить - т.е. остаться в текстовом представлении (пусть с "расцветкой" синтаксиса) - и тут общее поле с ББ. Это я и имел в виду. ДРАКОН же (а точнее - шампур-метод и графит-метод как его развитие) находятся в другом поле - где мы уходим от чисто текстового представления знаний к "графитному". PureBuilder - это вовсе не "расцветка" синтаксиса. PureBuilder имеет не больше текстового представления, чем Дракон. Просто Дракон - это двумерная блок-схема, а PureBuilder - одномерная - вытянутая только в вертикальном направлении. Связи между блоками обозначаются в Драконе линиями, а в PureBuilder - вложенностью блоков, ветвями многоветочных конструкций, модульностью, передаваемыми параметрами и т.п. Разнообразие инструментария в PureBuilder позволяет каждый объект разрабатываемой программы изобразить наиболее подходящим способом, естественнее и проще для восприятия. Там, где это целесообразно, в PureBuilder используются графы, например, для отображения связей между модулями. |
Автор: | Владислав Жаринов [ Вторник, 11 Январь, 2011 06:27 ] |
Заголовок сообщения: | О качестве реализации сред формализации |
Сергей Прохоренко писал(а): Валерий Лаптев писал(а): ...Единственный пока минус - реализовано на Додиезе в VS 2010/ Просто они сейчас это изучают по одной дисциплине, и у него все " в пальцах". Ничего, потом перепишем. Это просто замечательно! Додиез - может быть, даже и плюс - на нем может получиться привлекательный интерфейс. |
Автор: | Владислав Жаринов [ Вторник, 11 Январь, 2011 06:34 ] |
Заголовок сообщения: | Ещё раз о целях и средствах :) |
Сергей Прохоренко писал(а): Драконограф писал(а): Вы предлагаете как раз уходить - т.е. остаться в текстовом представлении (пусть с "расцветкой" синтаксиса) - и тут общее поле с ББ. Это я и имел в виду. ДРАКОН же (а точнее - шампур-метод и графит-метод как его развитие) находятся в другом поле - где мы уходим от чисто текстового представления знаний к "графитному". PureBuilder - это вовсе не "расцветка" синтаксиса. PureBuilder имеет не больше текстового представления, чем Дракон. Просто Дракон - это двумерная блок-схема, а PureBuilder - одномерная - вытянутая только в вертикальном направлении. Связи между блоками обозначаются в Драконе линиями, а в PureBuilder - вложенностью блоков, ветвями многоветочных конструкций, модульностью, передаваемыми параметрами и т.п. Разнообразие инструментария в PureBuilder позволяет каждый объект разрабатываемой программы изобразить наиболее подходящим способом, естественнее и проще для восприятия. Там, где это целесообразно, в PureBuilder используются графы, например, для отображения связей между модулями. Вот есть следование "блоков" (наверное, правильно заимствовать из РБНФ-технологии описания термин SeqStatement). В шампур-методе оно показывается связкой блочных вершин звеньями вертикали; какими средствами в документе Вашей среды его будем обозначать? И есть ветвление - какие у Вас средства изображения "многоветочных конструкций"? Модульность - её саму надо выразить в документе; я применительно к Оберон-подобным языкам предлагаю на графовой основе ПК-язык, практическое употребление можно найти на листе 5 в этом примере - какими средствами предлагаете Вы? Передача параметров - тоже логический механизм. Физику я предлагаю отобразить целостно в ДМ-языке - через совмещение применительно к вызову процедуры формальных и фактических параметров - пример в ДМ-схеме на этой картинке. Вложенность блоков - что имеется в виду? Текстуальное вложение процедур деятельности (в частном случае - программных)? Возможно его визуализировать средствами АТ-языка, предварительно определяемого здесь - примеры см. Листинги 73...75 здесь. Вопрос опять тот же... Ещё один более общий вопрос - раз структуру импер-маршрутов Вы предлагаете компоновать одномерно - т.е. придать ей лиоформу в смысле определения в конце этого подпункта (как я понимаю, это касается и деклар-отношений, и актив-связей - буде Вы решите всё-таки и этот неотъемлемый компонент частного знания о задаче дать возможность фиксировать в своей среде, а не где-то отдельно) - какими средствами предлагается укладывать нелинейные структуры на плоскости документа без пересечений? С чисто текстовым представлением (без накладки структурографирующих элементов в виде тех же межстрочных скобок) более-менее понятно - но если Ваша среда поддерживает не только его - тогда как? Уже оструктуривание текста м.б. проблематичным - если маршруты пересекаются. Паронджанов предложил силуэтизацию для графов (маршрутных) - что у Вас? Тут может возникнуть вопрос - а что, не ограничиться ли в среде тем, что как-нибудь зафиксировать содержание текста программы, дав средства изображения его отдельных составляющих "наиболее подходящим образом" - и хватит с юзеров? Почему так не пойдёт - объяснял уже в конце предыдущего поста. Если моего слова как "предметника" недостаточно - послушаем создателя автоматного программирования (курсив авторов): Поликарпова, Шалыто на с. 8 писал(а): Отметим, что термин "программирование" в этой книге употребляется в широком смысле. Как процесс он означает то же, что и "разработка", "создание" программного обеспечения. Как разновидность (в словосочетаниях "автоматное программирование", "объектно-ориентированное программирование" и т.п.) он является синонимом терминов "метод", "подход", "парадигма". Для обозначения программирования в узком смысле (написания понятного компьютеру кода) в книге используется термин "реализация". Речь идёт о книге, анонсированной в этом сообщении. В дискуссионных целях, наверное, дам выдержки из неё - там же.Вот "программирование в широком смысле" по Шалыто - это то же, что "формализация знаний о задаче до уровня командных моделей с программной составляющей" в смысле иерархии двуединого процесса моделирования/формализации, обсуждаемой в этом пункте. Далее в книге, кстати, обсуждается, как зафиксировать в спецификациях решения задачи и актив-знание (об исполнителе) - в рамках целостной с импер- и деклар-знаниями модели решения. Итак, в ходе моделирования/формализации вся ролевая триада "предметник-аналитик-программист" (а не только третий её участник) накапливает постепенно информатизуемое знание о задаче (а заодно и о каких-то других, и обо всей "предметке"). Часть этого знания обобщённая - её вообще не всю информатизуют - просто дают в "паспорте" задачи текстом (ограниченным, математическим). Понятие паспорта обсуждается в этом подразделе. И надо предоставить возможность участникам триады (это м.б. как люди, так и коллективы - лишь в частных случаях один человек совмещает какие-то две или все три роли) создавать весь паспорт задачи в одной среде от начала до конца. Это элементарное требование экономики - что получается, если ему не следовать, показано на примере разбора одной существующей среды описания в п/р 6.2 документа, вложенного в это сообщение.
Вообще хотелось бы видеть прежде всего определение комплекса языков, поддерживаемых средой - начиная с качественного, как на страницах этого раздела. Не забывая про общеязыковые требования - которые у меня, допустим, качественно даны на этой странице, а исходят из некоего общего представления, эскизно сформулированного в этом сообщении. И представлении о технологии формализации - хотя бы качественное опять же, как в этом сообщении. Это уже м.б. реальным предметом обсуждения. P.S. Неточно дал ссылки на АТ-язык и примеры - на конференции в сообщениях только начальные варианты, а рабочие - в Драконографике, где возможности для форматирования шире Исправлено выше в сообщении. |
Автор: | Владислав Жаринов [ Вторник, 11 Январь, 2011 08:22 ] |
Заголовок сообщения: | Re: Ещё раз о целях и средствах :) |
В отношении всё того же - можно почитать публикации в этом соообщении. Есть над чем подумать... и проструктурировать "предметку" PureBuilder. |
Автор: | Владислав Жаринов [ Вторник, 11 Январь, 2011 09:37 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Валерий Лаптев писал(а): ...Основные особенности - язык программирования минимальный и русский. С учетом изысканий, которые по форме цикла Дейкстры мы тут однажды провели. А что за изыскания?
|
Автор: | Владислав Жаринов [ Вторник, 11 Январь, 2011 11:16 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Александр Ильин писал(а): Цитата: PureBuilder должен, оставаясь по-возможности лаконичным, наглядными средствами поддерживать разнообразные (но не любые существующие) парадигмы программирования: Предлагаю скорректировать название проекта: PureeMasher.
Функциональное программирование Логическое программирование Процедурное программирование Структурное программирование Объектно-ориентированное программирование Обобщенное программирование Компонентно-ориентированное программирование Параллельное и распределенное программирование Как обещал в этом сообщении, вложил выдержку из самой работы по автоматному программированию в это сообщение. Актуальна, очевидно, будет увязка с описанным ещё и графит-деклар-моделей. Интересно, было ли это у Шалыто... знатоки SWITCH-методологии, ау-у... |
Автор: | Galkov [ Вторник, 11 Январь, 2011 11:18 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Есть у меня изначально какое-то не понимание фундаментальной цели.... Ну зацепимся за такое, к примеру: Сергей Прохоренко писал(а): Связи между блоками обозначаются в Драконе линиями, а в PureBuilder - вложенностью блоков, ветвями многоветочных конструкций, модульностью, передаваемыми параметрами и т.п. Бог с ним с Драконом (на минутку хотя бы)Но с какой такой радости, генерируя семантическое дерево (почему не ДАГ?) программы, мы считаем наиболее удобным способом вводить его в "линейном виде с нужными отступами" Кто не дает вводить дерево - именно как дерево ??? Ну типа: узел дерева IF - от него отходят две ветки. Которые в свою очередь... ну Вы в курсе. Представьте себе "инопланетянина", в достаточной степени познавшего Человеческую культуру, и попробуйте ему втолковать Величие Текста с Отступами |
Автор: | Владислав Жаринов [ Вторник, 11 Январь, 2011 11:28 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Galkov писал(а): Есть у меня изначально какое-то не понимание фундаментальной цели.... Да, вот в том-то и штука - если и отвлечёмся от граф-импер-языка - всё равно есть вопросы к логике и физике модели как таковым - и Ваши, и поставленные в этом сообщении... а может, и ещё какие...Ну зацепимся за такое, к примеру: Сергей Прохоренко писал(а): Связи между блоками обозначаются в Драконе линиями, а в PureBuilder - вложенностью блоков, ветвями многоветочных конструкций, модульностью, передаваемыми параметрами и т.п. Бог с ним с Драконом (на минутку хотя бы)...Среди "ещё каких" - обеспечение ссылки на разные описания одного и того же по имени. |
Автор: | Geniepro [ Вторник, 11 Январь, 2011 12:38 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Galkov писал(а): Представьте себе "инопланетянина", в достаточной степени познавшего Человеческую культуру, и попробуйте ему втолковать Величие Текста с Отступами Chris Okasaki, "In praise of mandatory indentation for novice programmers" |
Страница 2 из 7 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |