Здравствуйте, Дарней, Вы писали:
Д>Тут я никак не могу согласиться. Текстовые файлы как минимальная единица исходного кода — это просто атавизм, который сильно мешает дальнейшему развитию. К примеру, возьмем средства, расширяющие возможности студии — всякие там решарперы, visual assist'ы и together. Если нужно поставить более чем одно из таких средств, то каждое из них хранит свою собственную копию AST кода и следит за ее актуальностью, что выливается в затраты памяти и проблемы с синхронизацией между ними. Например, resharper + together = очень нехилые тормоза при любом рефакторинге.
И, что это мешает им работать с текстовыми файлами в которых лежит код? Что-то я не заметил, чтобы у них возникала потребность в бинарном формате.
Д>Плюс к этому, хранение кода на уровне элементов AST намного упростит работу с VCS.
У нее и так проблем нет.
Д> К примеру, можно будет получить список изменений, которые проводились только в интересующей тебя функции, а не во всем файле, где она находится.
Это можно сдлеть и так. Берешь две версии и сравнивашь изменения с помощью ФЫТ-шного дифа.
В общем, нет потребоности в каком-то ином формате. Все прекрасно живет в файлах. Ну, и еще раз объекты тут не причем. Вы все говорите о сравнении исходников по АСТ. А это никакого отношения к объектной модели приложения не имеет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Порядка 20 секунд. Большую часть времени занимает связывание.
И исходники какого размера?
C>С++, однако.
Во-во.
C>А ничего не сделать — используется куча библиотек, и при линковке они C>должны подгружаться. Инкрементальное связывание помогает, но не сильно.
Дык и другие кучу бибилотек исползуют. Причем скорее всего куда большую кучу. Но модульность позволяет сильно ускорить сборку приложения и не занимать сотни мег оперативки и гигабайты места на винте.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Совсем сократить программу все же нельзя: остаются декларации типов. Это можно поправить, поскольку оператор foreach обладает необходимой информацией о типе IEnumerable, стоящего в его аргументе, а, стало быть, мог бы вывести тип первого аргумента: S>
S>foreach(/*int*/ a in/*(IEnumerable<int>)*/array)
S> sum+=a;
S>
C# 3.0:
var sum = 0;
foreach(var a in array)
sum += a;
Типы выводятся автоматом. Тип sum выводится из ее инициализатора. Например, вот так:
var sum = 0L;
будет long, а так:
var sum = 0.0;
double.
S>С суммой ситуация хужее. Ее тип, теоретически, тоже можно было бы вывести из типа складываемых аргументов (по крайней мере, агрегатная функция SUM в SQL это делает).
Из аргументов? Это только если проанализировть все вхождения. Шарп поступает проще. Да и насколько я знаю другие языки тоже.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Dyoma, Вы писали:
D>Речь шла о возможности думать на языке, на котором пишешь, а не переводить свои мысли с русского. Smalltalk как демонстрация императивного мышления, ML — функционального.
Твое "думать" это всего лишь означает использовать некие абстракции позвляющие выражать мысли паттернами, а не угадывать паттерны в коде. Потому и пример содержит for, а не foreach (хотя в яве он тоже выражается ключевым словом for, но это уже мелочи). Как только вместо for-а появляется foreach, то проблем с распознованием паттерна еже нет. А учитывая, что можно и более высокоуровневый паттерн выделить в фунцию (т.п. создать функцию Sum), то становится понятным, что чтобы думать на языке нужно не другой язык, а умение абстрагировать выражение мыслей на имеющемся языке.
Однозначно языки обладающие функциональными возможностями предоставляют большее количество средств для функциональной декомпозиции и тем самым позвляют лучше асбрагировать мелкие участки кода. Но тем не менее это не значит, что на Яве нельзя писать так же понятно как и на МЛ. Что же касается Смолтока, то и на нем есть все что нуно. Но вот твои примеры как раз эти возможности игнорируют. Ведь даже "инжект" это уже детали реализации паттерна сложения элементов который еще нужно угатадать. А если ты еще не знашь как работает "инжект", то и более высокоуровневый паттерн сложения угадать неудаствая. А вот из банального foreach-а он угадывается очень хорошо. Так что я считаю, что тут как раз Смолток менее понятен.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>Функции-друзья. Несколько нарушающие инкапсуляцию, я думаю, стали ответом на зашоренный взгляд мира ООП — оказывается, необязательно иметь только вертикальные связи (наследование и жёсткая иерархия), но можно работать и на горизонтали (функции-друзья), сосуществуя в p2p-пространстве. Не это ли некое отражение идеи mixins в C++?
Ничего более похабного чем концепции friends в C++ не видел. Сплошной и дурнопахнуйщий хак. Мне нужно чтобы я мог сказать, что этот класс A знает что существует класс B и именно для B доступна именно функция A.method. Тогда при изменении A.method, я знаю что неплохо бы и адаптировать поведение в классе B. Вот так было-бы неплохо.
Здравствуйте, VladD2, Вы писали:
VD>Ведь даже "инжект" это уже детали реализации паттерна сложения элементов который еще нужно угатадать.
Как раз "инжект" -- это не паттерн сложения. По крайней мере в Ruby, который inject позаимствовал из Smalltalk. В качестве inject-а может быть и произведение элементов.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Твое "думать" это всего лишь означает использовать некие абстракции позвляющие выражать мысли паттернами, а не угадывать паттерны в коде.
Сначала угадывать, а потом вносить в мой словарный запас (варианты: набор понятий, которыми я думаю; набор патернов). Словарный запас стандартной библиотеки тоже очень стоит внести в свой (а не изобретать велосипеды). Я писал о том, что C\Java\С#(<3.0) не имеют естественных средств выражать многие патерны.
Еще из примеров с коллекциями: поиск элемента по условию, фильтрование коллекции, конвертация, ...
VD>Потому и пример содержит for, а не foreach (хотя в яве он тоже выражается ключевым словом for, но это уже мелочи).
Про foreach я отлично знаю, это очень здорово, что он наконец-то появился. А то что его не было сразу — показывает, что о думании на языке программирования не подумали.
VD> Как только вместо for-а появляется foreach, то проблем с распознованием паттерна еже нет. А учитывая, что можно и более высокоуровневый паттерн выделить в фунцию (т.п. создать функцию Sum), то становится понятным, что чтобы думать на языке нужно не другой язык, а умение абстрагировать выражение мыслей на имеющемся языке.
А что когда я функцию писать буду мне там патерн не надо выделять? inject:into: — патерн очень общий, а функция sum — очень частный. И таких sum и аналогов в каждой проге (ok, написанной год и более назад) дофига.
VD>Однозначно языки обладающие функциональными возможностями предоставляют большее количество средств для функциональной декомпозиции и тем самым позвляют лучше асбрагировать мелкие участки кода. Но тем не менее это не значит, что на Яве нельзя писать так же понятно как и на МЛ. Что же касается Смолтока, то и на нем есть все что нуно. Но вот твои примеры как раз эти возможности игнорируют. VD> Ведь даже "инжект" это уже детали реализации паттерна сложения элементов который еще нужно угатадать.
В одном месте я складываю, в другом умножаю, в третьем ищу наибольшее четно число. Это что все высокоуровневые патерны? Их надо выделять? А по-моему, надо просто не мешать человеку увидеть что именно делается с коллекцией.
VD>А если ты еще не знашь как работает "инжект", то и более высокоуровневый паттерн сложения угадать неудаствая.
Как работает инжект известно хорошо, когда он часто использован.
VD> А вот из банального foreach-а он угадывается очень хорошо. Так что я считаю, что тут как раз Смолток менее понятен.
Код на Смолтоке показывает, что просто итерация по коллекции — патерн очень бесполезный и используется в основном в библиотеке, для определения полезных.
Здравствуйте, Dyoma, Вы писали:
D>Код на Смолтоке показывает, что просто итерация по коллекции — патерн очень бесполезный и используется в основном в библиотеке, для определения полезных.
Приведенный код показывает, что просто получение суммы двух чисел — паттерн очень бесполезный и используется в основном в алгоритмах, для создания полезных
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Не совсем зря. В c.l.s до сих пор(!) спорят о том, как можно было бы правильно его назвать. Но 30 летнею историю не перепишеш.
VD>А что мешало создать еще один метод который будет иметь имя Fold или Acumulate?
inject:into: "шире" fold:. В 1-м можно задать начальное значение плюс более сложные вычисления в блоке.
acumulate не отражает сути операции
ANS>>Но если так хочется понятности, то можно использовать fold:.
VD>То есть он таки есть? Ну, слава богу. Значит, скорее всего, есть и аналогичные в других странных местах?
Че?
VD>Тогда просьба к тем, то приводит примеры на Смолтоке: Будьте добры выбирать названия методов понятные тем, кто не знает и не хочет изучать 30-ти летнюю испторию Смолтока.
Краткое введение во внутренние итераторы Smalltalk-а.
do: — foreach; select: — выбрать элементы по условию; reject: — обратно к select: выбрать элементы не удовлетворяющие условию (отбросить по условию); collect: — к каждому элементу применить блок и вернуть коллекцию в которой результаты выполнения блока; в функц. языках обычно называется map; inject:into: — обсудили; detect: — вернуть первый элемент, удовлетворяющий условию, выбросить исключение если не найдено; detect:ifNone: — вернуть первый элемент, удовлетворяющий условию + можно обработать ситуацию отсутствия элемента;
Эти методы есть у всех коллекций. Не очевидный только inject:into:.
Хотя, конечно, проще развивать теорию о всеобщем счастье, которое наступит году к 2012, когда выйдет третья версия языка, у которого еще не вышла вторая версия.
Здравствуйте, VladD2, Вы писали:
VD>И, что это мешает им работать с текстовыми файлами в которых лежит код? Что-то я не заметил, чтобы у них возникала потребность в бинарном формате.
Им — не мешает. Мешает мне, который пытается использовать всю эту радость, отчаянно матерясь на тормоза и глюки
VD>Это можно сдлеть и так. Берешь две версии и сравнивашь изменения с помощью ФЫТ-шного дифа.
А если версий не две, а сто, и мне нужно найти ту, в которой изменилась одна-единственная нужная мне функция?
Здравствуйте, Дарней, Вы писали:
Д>Им — не мешает. Мешает мне, который пытается использовать всю эту радость, отчаянно матерясь на тормоза и глюки VD>>Это можно сдлеть и так. Берешь две версии и сравнивашь изменения с помощью ФЫТ-шного дифа. Д>А если версий не две, а сто, и мне нужно найти ту, в которой изменилась одна-единственная нужная мне функция?
svn blame/cvs annotate спасет отца советской демократии.
А вообще, идея с бинарным репозиторием исходных файлов, с которым IDE работает напрямую, была опробована в VisualAge for Java. Успешно провалилась
Здравствуйте, Cyberax, Вы писали:
Д>>А если версий не две, а сто, и мне нужно найти ту, в которой изменилась одна-единственная нужная мне функция? C>svn blame/cvs annotate спасет отца советской демократии.
а если меня интересует, какой [self-censored] нехороший человек стер ту ветку кода, которую я добавил в функцию полгода назад?
C>А вообще, идея с бинарным репозиторием исходных файлов, с которым IDE работает напрямую, была опробована в VisualAge for Java. Успешно провалилась
Я не очень то много работал с Явой, а VisualAge и вовсе ни разу не видел А что с ней было не так?
Здравствуйте, Дарней, Вы писали:
Д>А если версий не две, а сто, и мне нужно найти ту, в которой изменилась одна-единственная нужная мне функция?
А какая разница для дифира бинарный формат или плоский текст? Он один хрен будет сравнивать версию с версией.
Находится же нужная версия довольно просто. Смотришь "среднюю версию" (т.е. между самой старой и самой свежей). Если в ней изменение уже есть, то смотришь среднюю версию между этой и самой старой. Если нет, то между этой и самой новой. Ну, и так далее пока не останется 1 файл. В общем, бинарный поиск.
В принципе если АСТ-шный дифер будет, то приделать автоматизацию поиска уже ничего не мешает.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>а если меня интересует, какой [self-censored] нехороший человек стер ту ветку кода, которую я добавил в функцию полгода назад?
Тогда тебе нужен именно текстовый дифер без каких бы то ни было извратов.
Д>Я не очень то много работал с Явой, а VisualAge и вовсе ни разу не видел А что с ней было не так?
VisualAge — это вообще вещь в себе. Ни как не забуду как в 95 году, когда у народа было по 4-8 метров на машинах эти орлы вывалили VisualAge фор что попало который даже для С++ требовал минимум 64 метра памяти.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
VD>>Ведь даже "инжект" это уже детали реализации паттерна сложения элементов который еще нужно угатадать.
E>Как раз "инжект" -- это не паттерн сложения. По крайней мере в Ruby, который inject позаимствовал из Smalltalk. В качестве inject-а может быть и произведение элементов.
Как ты там мне говорил? Учисть читать что написал...
В общем, обрати внимание на выделенное жирным. Я имею в виду, что в коде используется паттерн "сложнеие", а через "инжект" он реализован или через "форич" уже не так важно. В коде уже детали реализации, а не абстракция сложения. Если хочешь чтобы код был максимально понятно, то нужно все такие места (ну, до разумных приделов) выделить в отдельные функции. Провести, тык-сызать, функциональную декомпозиции.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Дарней wrote:
> Д>>А если версий не две, а сто, и мне нужно найти ту, в которой > изменилась одна-единственная нужная мне функция? > C>svn blame/cvs annotate спасет отца советской демократии. > а если меня интересует, какой [self-censored] нехороший человек стер > ту ветку кода, которую я добавил в функцию полгода назад?
Это и есть суть команды blame (удачное имя ) — она показывает в какой
ревизии (и кем) изменялась данная строчка. А вообще, с нормальной SCM
проблем посмотреть историю изменений обычно не возникает.
> C>А вообще, идея с бинарным репозиторием исходных файлов, с которым > IDE работает напрямую, была опробована в VisualAge for Java. Успешно > провалилась > Я не очень то много работал с Явой, а VisualAge и вовсе ни разу не > видел А что с ней было не так?
Неудобно работать было — для всех внешних тулзов приходилось
экспортировать исходники. Ну и визуальное программирование нафиг никому
не нужным оказалось.
