Форум 'Философия программирования' на RSDN.RU

Свежий взгляд на IDE

Thu, 11 Mar 2010 18:36:56 GMT

Доброго времени суток,

натнулся тут на любопытный ролик здесь
Он демонстрирует свежий подход к организации интерфейсп пользователя IDE (по крайней мере авторы нашли применение огромным расширениям современных широкоформатных дисплеев). Авторы предлагают опять-таки отойти от привычной парадигмы работы с текстовыми файлами, и рассматривать отдельные куски кода, которые пользователь в процессе работы может как угодно группировать, для облегчения навигации по коду. При этом не затрагивая структуры файлов.
По крайней мере выглядит это эффектно.
Вопрос собственно говоря следующий — имеет ли подобная технология право на жизнь, или это просто никому не нужное украшательство, за которым приятно наблюдать, но не работать?

Цена МН

Tue, 09 Mar 2010 10:11:14 GMT

Навеяно веткой "[ООП] Хочу странного".

Как известно, все имеет свою цену. В том числе, наличие множественного наследования и его отсутствие. Поэтому для вменяемых людей вопроса "Быть МН или не быть" не стоит. Стоит вопрос, что перевешивает в данных конкретных обстоятельствах. Если бы МН ничего не стоил, так кому бы он мешал.

Так вот, пытаясь сообразить, какова цена МН, понял, что все читанные мной дискуссии крутятся вокруг того, что МН позволяет наделать гадостей. Но ведь это цена, которую платит создатель языка, а не программист. Микрософту захотелось, чтобы язык пользовался репутацией надежного, и они поубирали оттуда все, что представляло опасность, в том числе, наследование. Но это именно цена, предъявленная Микрософту, потому, что программисты одной группы какого-нибудь ISV вполне могут просто договориться не пользоваться МН, и сам язык тут не при чем.

Так вот, а какова цена, предъявленная за наличие МН именно программисту? Допустим, в C# добавили бы МН, что бы мы неизбежно потеряли? Студия бы тормозила от повысившейся сложности?

Какой длины должно быть имя файла?

Tue, 09 Mar 2010 08:56:11 GMT

Не знаю, соответствует ли данный форум вопросу, но пока спрошу тут.
Какой максимальной длины должно быть имя файла?
И какой максимальной длины может быть имя пекеджа?
Как вы думаете?
Есть какие-то ограничения?

Современные проблемы программирования

Mon, 08 Mar 2010 12:26:37 GMT

Пишу код и решил проанализировать, почему несмотря на наличие среды разработки, простой язык, всяческие конструкции управления так долго приходится писать вообщем то простые вещи. Пришел к выводу, что большую часть времени занимает написание кода преобразования данных их одних форматов в другие: из полей в таблицы, из массивов в строки и наборот.
Вот получили результат вычисления, но дальше кго надо перепаковать в другой формат и отдать другой процедуре на обработку, определить соответсвие переменных, считай — понятий. Понятия эти проходят НАД программой в момент её проектирования, но прячутся, как жевачка в волосах В ТЕКСТЕ, когда программу пишешь или еще хуже — читаещь чужой код.

Прихожу к выводу, что объекты — это только "часть правды". Объекты, как концентрация нашего "проектного представления" о программе безусловно полезны. Но вот если бы еще вынети ДАННЫЕ на верхушку программы и вынести их как обязательную конструкцию. Данные — унифицировать по строению, — как таблицы в СУБД. А между ними прописать явняе отношения — как особые конструкции вроде SQL. Вызова процедур и функций как последовательности операторов избегать совсем. Функция — пусть будет как объект, который может принять на себя ДАННЫЕ, и выдать ДАННЫЕ, которые уже вынесены в отдельную область программы. Функция — по сути носитель отношения. Они могут образовывать суперпозиции — опять аналогия с SQL. Добавить принцип — любые данные могут быть рождены только одной функцией, но потребляться могут несколькими — и программы превратятся в понятные, легко конструируемые графы.
Ваше мнение.

[ООП] Хочу странного

Mon, 08 Mar 2010 10:31:51 GMT

При спорах вида "С++ vs X", где Х — любой объектно-ориентированный ЯП, поддерживающий единичное наследование, неизбежно возникает ответвление спора на тему "множественное наследование vs. единичное наследование". Защитники МН упирают на бОльшую гибкость и возможности, которые дает МН, противники — на то, что МН усложняет реализацию языка, сам язык и что МН вообще не нужно.

Мое личное мнение состоит в том, что если рассматривать классическое ООП в стиле Smalltalk, то правы оппоненты МН. Если же рассматривать ООП и как инструмент создания архитектурного каркаса ПО, то я выступаю за МН, ибо он дает хорошие возможности по комбинации функциональности, в частности реализуя возможность mixin-style.

Теперь, собственно, к странному. А надо ли вообще в языке иметь наследование реализации в том виде, в котором это сделано в том же C++/C#/Deplhi/Java т.д.? Что в этих языках имеется в виду, когда говорится "Класс Б наследует класс А"? Имеется в виду две вещи:
1. Класс Б является подтипом А, т.е. поддерживает интерфейс класса А, и является легальным для применения везде, где можно применять А. Это Liskov substitution principle (http://en.wikipedia.org/wiki/Liskov_substitution_principle).
2. Класс Б наследует всю реализацию класса А, его поля и методы, т.е. повторно использует реализацию класса А.

Другими словами, в таком наследовании мы имеем смешение двух идей:
1. Абстракция через обобщение.
2. Повторное использование кода.

Что если принципиально разделить эти вещи? Абстракция через обобщение в чистом виде есть во многих языка в виде интерфейсов, которые, кстати, поддерживают множественное наследование даже там, где классы поддерживают только единичное. Повторное использование кода тоже возможно другим способом — через композицию объектов. Единственное, чего нет — это синтаксически хорошо оформленное делегирование реализации интерфейса/части интерфейса композитам, из которых составлен класс-композиция. Но это не сложный аспект, который можно реализовать.

Данный подход не имеет тех недостатков МН, на которые упирают его противники и в то же время он обеспечивает все его возможности + кое-что сверху. Ваши мнения, коллеги?

Динамические языки и переменные

Fri, 05 Mar 2010 15:46:00 GMT

Вопрос такой.
Многие динамические языки позволяют неявно объявлять переменные (некоторые даже и вовсе не имеют синтаксиса для явного объявления, но это другой вопрос).
При этом в ряде случае такое объявление не рекомендуется.

Возьмем всем известный ДжаваСкрипт. Там объявление переменной без var считается моветоном, хотя бы потому что его семантика кардинально отличается от объявления с var (однако по коду это совершенно неочевидно):

function Foo()
{
  var x = 1; //переменная в скопе Foo
  y = 2; //А вот уже переменная в глобальном скопе
}

Если рассматривать проблему с т.з. ДжаваСкрипта, то там и вовсе становится непонятно, зачем нужна возможность неявного объявления. Я, к примеру, так не пишу никогда.
Но с другой стороны вышеуказанный пример и:

var obj = {};
...
obj.y = 2;

Вещи в принципе родственные.

Собственно, мой вопрос, как вы считаете — если в языке есть синтаксис для явного объявления переменных, насколько необходима поддержка неявного объявления? Если эту возможность убрать (т.е. в примере выше была бы ошибка) потеряет ли язык в выразительности?

var/alias

Thu, 04 Mar 2010 11:06:25 GMT

Неоднократно видел в коде, как переменные создавались только для того, чтоб не писать везде далее исходное выражение.

Например:

bool bLalamba = pEnga->InternalLalamba.LalambaMember;
...
Foo(bLalamba);
Bar(bLalamba);
return bLalamba;

С выведением типов это немножко красивее:

var lalamba = enga.InternalLalamba.LalambaMember;
...
Foo(lalamba);
Bar(lalamba);
return lalamba;

Созрели вопросы: что эффективнее в современных компиляторах — заводить переменную на стеке или несколько раз находить адрес? Кэшируется ли для этого адрес? Есть ли языки, где кроме var'а доступен какой-нибудь alias (если бы не глобальность плюсовых макросов, они бы сгодились)?

Вопрос по грамматике

Thu, 04 Mar 2010 08:11:28 GMT

Бизон выдает 2 конфликта сдвиг/свертка на следующей грамматике:

%left ADD
%left MUL

%%

expr : expr bin_op expr
    | NAT
    ;

bin_op : ADD
    | MUL
    ;

Один человек, разбирающийся в подобных вещах, сказал, что грамматик, допускающих подобным образом выделение bin_op в отдельное правило без кофликтов, не существует. Мне не верится — ни GLR, ни Earley? Выглядит так просто. Хотелось бы услышать еще подтверждение — он прав?

out- и ref-параметры.

Mon, 22 Feb 2010 20:02:16 GMT

Коллеги!
Предлагаю обсудить применение out- и ref-параметров, их достоинства и недостатки. Причем, в рамках существующих индустриальных языков (лично меня интересуют C++ и С#). У меня сложилось интуитивное ощущение, что их использование — это code-smell и вообще дело нехорошее. У меня есть на этот счет кое-какая аргументация, но хочу услышать мнения корифеев. Ссылки на статьи, где плюсы и минусы сабжа хорошо раскрываются, приветствуются.

Вопрос по приемлемости синтаксисической конструкции

Sun, 21 Feb 2010 07:17:04 GMT

Как бы вы отнеслись к конструкции

for i in 0..10

в которой 0..10 означает от 0 (включительно) до 9 (включительно), а не от 0 до 10?
На странице "syntax across languages" нет ни одного ЯП с таким правилом.

Фокус с копирайтом

Wed, 17 Feb 2010 07:26:20 GMT

Производим следующие действия, следите за руками

Берём исходники ядра linux и лезем, например, в файл cgroup_debug.с
В license header этого файла читаем:
Copyright (C) Google Inc, 2007

Или, например, в relay.c видим:
Copyright (C) 2002-2005 — Tom Zanussi (zanussi@us.ibm.com), IBM Corp

Получается, GPL — не GPL, а копирайты всё равно торчат, как опята на пне?
Я всегда думал: копирайт == исключительное право копирования. Проведите ликбез, пожалуйста, а то я даже не знаю, как вопрос для гугла сформировать.

Linq : неудачный маркетинг?

Tue, 16 Feb 2010 20:55:36 GMT

Добрый день.

По опыту своих бесед с программистами, не знакомыми с linq, я собрал ряд стереотипных заблуждений и проблем с пониманеим linq, которые у них встречаются. В целом среди них преобладает такое мнение "это убогий SQL в С#, зачем он нужен?". Все попытки объяснить, что linq является воплощением аппарата операций над множествами, который ортогонален языку, и с необходимостью которого никто не спорит, сталкиваются с такой стеной непонимания. Это приводит меня к мысли, что linq подан неудачно. Его SQL-подобный синтаксис вызывает затруднения и у тех кто не знаком с SQL (выглядит больно непривычно) и у тех, кто знаком (не совсем понимают, что SQL делает в языке и сталкиваются с тем, что синтаксис всего лишь похож, а не повторяет SQL). Мое мнение по этому поводу: Linq — хорошая штука, но неудачно подан. Ваши мнения?

что есть приемлемо...

Mon, 15 Feb 2010 10:08:53 GMT

Тема, конечно, не новая, но вот недавно проскочило одно сообщение, из-за которого я решил ее еще раз поднять.

Мне тут уже сто раз говорили : качественное ПО — это ПО, которое удовлетворяет требованиям пользователя.

И вот такое сообщение

http://rsdn.ru/forum/dotnet/3701783.1.aspx

Я не намерен здесь обсуждать дотнет.
Я не намерен обсуждать сериализацию ни как идею, ни как автор ее использует. Тем более, что ниже по ветке приведено иное решение, с иными совсем характеристиками. Его я также не намерен обсуждать.

Я просто одну фразу хочу прокомментировать.

>Сериализация проходит за приемлемое время...Скажем, 3 милиона элементов Dictionary сериализуются за 2 минуты в файл размером 150 МБ.

Так вот.

Вывод данных в файл размером в 150 Мб , если данные уже готовы и находятся в ОП, должен производиться за несколько секунд.

А автор пишет — 2 минуты приемлемое время.

А что значит приемлемое ? Пользователя устраивает ? Видимо, да. Появляется какой-то там диалог с песочными часами, ждите 2 минуты... Пользователь доволен — все работает, ну а то, что приходится ждать 2 минуты — что же поделать, программа сложная, данных много (миллионы!), так что терпите. Вот 20 минут на десериализацию убедить пользователя подождать, видимо, уже не удается.

Вот к чему приводит этот критерий "качества", с позволения сказать.

Вот и имеем дело мы с таким "качественным" ПО. С Visual Studio, которая solution с парой проектов грузит десяток-два секунд. С Office или Open Office, который стартует десяток секунд.

Мы к этому уже привыкли. Это для нас приемлемо. Использовать мощность компьютера на 5-10% — это приемлемо.

Джоэл. И снова о программировании

Sat, 13 Feb 2010 13:18:21 GMT

Статья:
Джоэл Спольски. Джоэл. И снова о программировании

Авторы:
Сергей Тепляков

Аннотация:
Продолжение вышедшего в 2006 году бестселлера "Джоэл о программировании" представляет собой подборку самых популярных статей. Исключительный писательский талант, техническая эрудиция и язвительный ум Джоэла создали ему высочайшую профессиональную репутацию и принесли его сайту скандальную известность. В книге затронуты разнообразные вопросы, касающиеся разработки и проектирования программного обеспечения, управления софтверным бизнесом, эффективного поиска и привлечения высококлассных сотрудников, организации рабочего места и общения с заказчиками. Автор предлагает практические советы как программистам, так и тем, кто руководит их работой.

Формальные ЯП и мейнстрим

Wed, 10 Feb 2010 09:13:05 GMT

Навеяно веткой Интересная статья Парнаса о верификации программ. Чтобы не оффтопить, вынес сюда.

Исходный посыл (deniok):

Уже всем давно понятно, что современные мейнстримовые языки должны умереть — у них абстракции текут; нет определенной формальной семантики, только стандарты "юридического" качества; ПО на них написанное без аннотирования, требующего работы на порядок бОльшей, чем затрачено на его написание, не допускает мало-мальски содержательного формального анализа.

Вопрос: а как вы представляете формальные ЯП, способные потеснить сегодняшний мейнстрим?

Я вот никак, по ряду причин:

1) Как уже упоминалоь где-то рядом, разработка ПО хорошо так специализирована. Что хорошо для "ПО на выброс", то не пойдёт в корпоратив и наоборот. Сегодняшний мейнстрим — жуткая солянка, где каждый язык хорош в своей нише и недостаточно силён, чтобы влезть в чужую.
1.1) На самом деле, слегка неправильно вообще говорить только об ЯП в контексте "кто кого заборет". Сопутствующий toolset и возможность взаимодёйствия с внешним API зачастую куда важнее всех фишек языка, особенно если mind model не совпадают.

2) Мейнстрим такой мейнстрим — либо решаем насущные задачи быстро/легко/дёшево/поддерживаемо (нужное зачеркнуть), либо в мейнстрим не лезем. А из насущных задач у нас что?
а) докрутить TUniversalComponent до рабочего состояния
б) автоматизировать бардак
в) как бы изловчиться и пнуть чужую систему чтобы она заработала.
г) найти ошибку в сложной логике с кучей условий и неочевидным code flow.
Как тут помогут формальные ЯП — хз.
2.1) Единственный почти декларативный мейнстримовый язык — SQL — хорошо показывает результат "хорошая идея vs суровая действительность".

3) Практически весь "свежий мейнстрим" — либо императивщина + чуть-чуть фп, либо декларативные высокоуровневые протоколы/стандарты описания данных (читай XML). На описание семантики никто не замахивается. Т.к. много их, ваших семантик. Плюс потихоньку пролазит декларативщина на низкий уровень, главным образом для описания state-машин (описание драйверов в сингулярити, Axum)

4) Если посмотреть на "мейнстрим из завтра", то у нас чётко видно 2 направления: виртуализация чего только можно и смесь DSL с императивщиной. На "формальная модель->код" никто пока не замахивается.

5) Возможность формальной валидации тьюринг-полного языка очень и очень сомнительна из-за нереальной размерности пространства состояний и слишком сложной формальной модели (по сравнению с реализацией "в лоб").
5.1) Валидность формальной модели вовсе не означает отсутствие ошибок в алгоритме, т.е. решающего превосходства формального подхода что-то не видно.

обособление аргументов

Thu, 21 Jan 2010 05:11:24 GMT

Здравствуйте всем.
Вопрос как по мне слегка надуманный, да и вообще у кого-то может вызвать праведную истерику. Кто-нибудь из присутствующих программистов когда-нибудь наперекор code конвенциям обособлял аргументы функций по краям пробелами? func( a, b ), вместо func(a, b), или это сродни придури? Спасибо.

24.01.10 02:56: Перенесено модератором из 'Архитектура программного обеспечения' — AndrewVK

Security@RSDN revealed

Tue, 19 Jan 2010 22:38:24 GMT

Итак, позволю себе потихоньку начать со введения (ибо без него — никак)

"Don't be evil" (c) Google Inc.

Мне нравится этот девиз, именно поэтому он заменил собой уже примелькавшееся слово "дисклеймер", а также потому, что он будет являться редлайном всего, что планируется здесь опубликовать. Хочу подчеркнуть, что цель данных публикаций — научить разработчиков защищаться, а не нападать. Поэтому, не будьте злыми, используйте полученные знания только в рамках принадлежащих вам проектов и систем, либо в которых вы принимаете непосредственное участие, с согласия их владельцев.

Для начала, предлагаю расставить точки над i относительно того, ЧТО здесь будет публиковаться, КАК, ЗАЧЕМ и КОГДА:

1. Что?

Постепенное раскрытие информации о мерах, предпринимаемых командой RSDN для усиления безопасности как данного ресурса, так и его пользователей (в рамках их сессий на данном ресурсе, разумеется).

2. Как?

Серией постов в этом топике, в формате, весьма близком к т.н. tutorials. Объясню, почему не статьи: к статьям предъявляются гораздно более жесткие требования по части оформления и содержания, а следовательно, на их подготовку уйдет больше времени и усилий, а следовательно, меньше времени и усилий получится потратить на, собственно, процесс. Т.к. процесс важнее, то предпочтительнее, на мой вгзляд, публикация постов в режиме online и живой диалог с их читателями, с возможной публикацией в будущем серии статей, основанных на этой теме с учетом высказанных тут пожеланий и заданных вопросов.

Кроме того, у меня пока еще нет опыта в подготовки настоящих, серьезных статей, и хочется сначала сделать дело, а уже потом пытаться завернуть это в красивую упаковку

3. Зачем

Целей две:

1. Сведение к минимуму рисков реализации информационных угроз как в отношении инфраструктуры ресурса, так и в отношении его пользователей.
2. Повышение осведомленности местного сообщества в вопросах обеспечения информационной безопасности на различных стадиях разработки, внедрения и эксплуатации информационных систем, через наглядные и живые примеры реализации тех или иных подходов и методик.

4. Когда?

Дабы не достичь эффекта, обратного озвученной в предыдущем пункте цели №1, информация будет публиковаться по мере того, как будут полностью устраняться выявленные угрозы. Этим, в частности, будут обусловлены значительные перерывы между публикациями, просьба отнестись к этому с пониманием. Со своей стороны, постараюсь выкладывать новые материалы не реже раза в неделю, но это не всегда будет зависеть только от меня.

Планируемая продолжительность первой итерации этого процесса колеблется в пределах 2-3 месяцев, что при традиционном умножении на e и pi дает нам сроки приблизительно в 6-9 месяцев соответственно. От них и будем отталкиваться

и еще одно:
5. Где?

Здесь, а не в "Веб-программировании" или "Обсуждении сайта", потому что речь пойдет не только о веб-приложениях (и не только о .NET-приложениях — см. ниже), а большинство подходов, методик, инструментов, уязвимостей и т.п. вполне применимы не только к вебу и rsdn.ru, но и к любому другому проекту, следовательно — это ontopic для ФП.

Забегая вперед (т.к. не проведя предварительный анализ исследуемого ресурса, мы не можем строить какие-либо планы по конкретным действиям с нашей стороны), озвучу приблизительный roadmap первой итерации:

#1. Собственно, проведем анализ инфраструктуры этого ресурса, чтобы аргументированно построить данный roadmap Узнаем как планировать меры по насаждению ИБ в проектах и какие подходы и методики мы можем при этом использовать.
#2. Проведем blackbox-тестирование библиотеки Rsdn.Framework.Formatting, в ходе которого построим и успешно испытаем свой собственный XSS-фаззер. Затем перейдем к проведению ревью безопасности кода этой библиотеки, после чего, самостоятельно закроем все найденные в ней уязвимости и выработаем рекомендации по дальнейшей безопасной разработке этого проекта. Кроме того, оставим после себя тяжелое наследие в виде unit-тестов, как-никак, но обеспечивающих снижение в будущем вероятности появления в библиотеке XSS-уязвимостей.
#3. Проделаем то же самое для библиотеки BLToolkit. Поскольку, если ничего не поменялось с лета прошлого года (я уже занимался тестированием BLT в рамках внедрения системы, ее использовавшей), серьезных уязвимостей мы там не обнаружим, то у нас будет уникальная возможность на живом примере понять: "а что же теперь делать с ней дальше? можно ли считать ее безопасной? ('конечно же нельзя' — прим. автора)"
#4. Проделаем то же самое для оффлайн-клиента RSDN@Home aka Janus + научимся строить полноценные модели угроз, адекватно оценивать риски информационной безопасности в проектах с нетривиальной архитектурой и вырабатывать/внедрять контрмеры по их снижению.
#5. Проведем несколько, различных с т.з. зрения используемых подходов, тестов на проникновение (пентестов) в веб-приложения rsdn.ru
#6. Проведем пентесты в окружение rsdn.ru (веб-сервер, сервер БД, ОС сервера, сетевая инфраструктура)
#7(бонусный). Опыт, полученный при исследовании Janus'а перенесем на другой оффлайн-клиент: RSDN@Linux aka Avalon. Наглядно увидим, чем отличается тестирование безопасности нативного приложения, от практически аналогичного ему .NET-приложения

Описания всех уязвимостей, используемого инструментария и т.п. будут приводиться по мере необходимости там, где они будут упомянуты или непосредствено перед этим. В конце каждого поста будет указываться реальный текущий статус этого процесса.

Дополнения и пожелания приветствуются.

Текущий статус:

#1 — завершен, публикация оформляется.
#2 — тестирование и ревью завершены, идет устранение обнаруженных уязвимостей.
#остальные — еще не были начаты.

Что такое "абстрактная интерпретация"?

Tue, 19 Jan 2010 17:27:37 GMT

Объясните "на пальцах", на наглядных примерах?

К вопросу о безопасности веб-приложений

Tue, 19 Jan 2010 16:49:52 GMT

Решил я себе все-таки завести блог. А если быть точным, то не завести, а оживить старый, давно заброшенный. Сижу, настраиваю, никого не трогаю, после тяжелого трудового дня. И, придумывая название для блога, подумал о том, что неплохо было бы назвать его как-то, типа:

'';!--"<kochetkov.vladimir@security>=&{()}

что как-бы должно символизировать (хинт: указанная строка, за исключением моего имени, является популярным вектором тестирования на подверженность XSS-атакам)...

Результат превзошел все ожидания, за подробностями — прошу в мой несостоявшийся блог: http://vkochetkov.blogspot.com/

Почему в философию? Видимо, потому что сие является наглядной демонстрацией:

а) железного правила написания безопасного кода: "все входящие данные — от лукавого"
б) того, как часто разработчики забивают на это правило

P.S: Подскажите плс, движок блога, который нормально схавает придуманное мной называние, плс. Уж очень оно мне понравилось

[ANN] Quick Security References

Tue, 19 Jan 2010 08:12:29 GMT

Новая инициатива от Microsoft'овских безопасников: цикл небольших статей, предназначенных для разработчиков и рассказывающих о наиболее наспространенных уязвимостях, причинах их появления и способах устранения в разрабатываемых продуктах (с уклоном на специфику MS платформ, разумеется). Здесь уже доступны статьи по XSS и SQL Injection.