Как перестать программировать на С++ в Паскаль стиле?

← →
@!!ex © (2009-05-11 18:43) [0]

После собеседования в одну фирму мне было сказано буквально следующее:
"Видно что у тебя большой опыт и понимание в этой сфере.
Но мы в затруднении, т.к. сейчас ты будешь программировать на С++ в паскаль стиле,
а для нас это не приемлемо. Поэтому вакансию мы не закрываем, если будет кто-то более опытный, то извини..."

Отсюда вопрос, как перестать писать в Паскаль стиле?

← →
turbouser © (2009-05-11 18:46) [1]

> @!!ex © (11.05.09 18:43)

> как перестать писать в Паскаль стиле?

Долго писать в стиле C++
Опыт одним словом..

← →
TUser © (2009-05-11 18:47) [2]

Лучше сразу читай мануал :)

http://forum.codenet.ru/album.php?albumid=5&pictureid=16

← →
DVM © (2009-05-11 18:49) [3]

> @!!ex © (11.05.09 18:43)

а конкретно глядя на что это было сказано?

← →
@!!ex © (2009-05-11 19:09) [4]

> [1] turbouser © (11.05.09 18:46)

Опыт же не изменится моего стиля программирования.

> [3] DVM © (11.05.09 18:49)

Смотрели проекты + смотрели немного кода + собеседование.

← →
@!!ex © (2009-05-11 19:11) [5]

> [2] TUser © (11.05.09 18:47)

Пока не актуально. Вот лет через 5 надо будет задуматься.

← →
Юрий Зотов © (2009-05-11 19:17) [6]

А зачем переставать писать в Паскаль стиле?

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

Есть всего два стиля программирования - плохой и хороший.

← →
Pavia © (2009-05-11 23:52) [7]

Совет один писать на Си и забыть про паскаль.
Стили отличаются но это не принципиально. Так как он меняется очень быстро. Другое дело что если человек не програмировал на Си или мало. То на освоение понадобиться время и компания скорее всего просто перестраховалась.

← →
Германн © (2009-05-12 02:07) [8]

> Pavia © (11.05.09 23:52) [7]
>
> Совет один писать на Си и забыть про паскаль.
> Стили отличаются но это не принципиально. Так как он меняется
> очень быстро

Да нет никаких "стилей"! Ну как вы не можете это понять?

Ну кроме указанных в Юрий Зотов © (11.05.09 19:17) [6]!

P.S. Вспомните сам сабж.

← →
Eraser © (2009-05-12 02:33) [9]

с появлением в Делфи Exit(Value) стиль стал еще ближе к сишному, вот тернального оператора не хватает только - это да.

← →
Игорь Шевченко © (2009-05-12 02:55) [10]

> Да нет никаких "стилей"! Ну как вы не можете это понять?

Стили есть, не надо рассказывать сказки. Поверь старому битому сишнику

← →
test © (2009-05-12 04:41) [11]

Eraser © (12.05.09 02:33) [9]

D7
x:= ifthen(a>b,a,c);

Есть только он в виде процедуры, чтобы сэкономить они под каждый тип свою процедуру написали код один и тот же.

← →
res novae (2009-05-12 08:26) [12]

1. Восхваляй Страуструпа каждое утро божие;
2. Прочти Annotated Reference Manual, что за авторством пророка нашего;
3. Прочти Design Patterns: Elements of Reusable Object-Oriented Software, дабы познать вкус ООП истинного;
4. Напиши что-нибудь нетривиальное с применением полученных знаний, например tcp/ip сервер с пулом соединений и очередью приоритетов;
5. Проклинай паскаль вечером каждого дня;
6. И воздастся тебе.

← →
Alex Konshin © (2009-05-12 09:21) [13]

[11] тернарный оператор и эти функции - это очень разные вещи и разница вовсе не в сокращении записи.

+= и ++ вроде есть в FreePascal.

← →
Григорьев Антон © (2009-05-12 10:01) [14]

Даже интересно, что они имели ввиду под сишным стилем. Это написание конструкций типа
while (*d++=*s++);
что ли?

Так это выжигать надо калёным железом.

← →
oxffff © (2009-05-12 10:19) [15]

> Eraser © (12.05.09 02:33) [9]
> с появлением в Делфи Exit(Value) стиль стал еще ближе к
> сишному, вот тернального оператора не хватает только - это
> да.

?

function TForm1.Ifthen<T>(LogicalExpression:boolean; const onTrue, onFalse: T): T;
begin
if LogicalExpression then exit(onTrue) else exit(onFalse);
end;

procedure TForm1.FormCreate(Sender: TObject);
var a:integer;
begin
a:=Ifthen<integer>(1>5,0,1);
end;

← →
KSergey © (2009-05-12 10:31) [16]

жыль, что не приведены конкретные примеры
Но я подозреваю, например:

try/finally (т.е. подстоение си-кода в таком стиле, без объектов-оберток)
неиспользование шаблонов (или слабое использование)

← →
oxffff © (2009-05-12 10:54) [17]

> вот тернального оператора не хватает только - это
> > да

Все хватает.

Tbc<A,B>=class
Type
TKeyPair=record
KEY:A;
Value:B;
end;
function GetPairFunc(aa:A;bb:B):TKeyPair;
public
class function CaseProc(Expression:A;const Keys:array of TKeyPair):B;
property GetPair[aa:A;bb:B]:TKeyPair read GetPairFunc;default;
end;
procedure TForm1.FormCreate(Sender: TObject);
var a:integer;
PObj:Tbc<integer,integer>;
begin
a:=Tbc<integer,integer>.CaseProc(10,[PObj[1,2],PObj[3,4],PObj[5,6],PObj[10,8]]);
showmessage(inttostr(a));
end;

{ Tbc<A, B> }

class function Tbc<A, B>.CaseProc(Expression: A; const Keys: array of TKeyPair):B;
var keyPair:TKeyPair;
Comparer:IComparer<A>;
begin
Comparer:=TComparer<A>.Default;
for keyPair in Keys do
if Comparer.Compare(keyPair.KEY,Expression)=0 then
begin
exit(keyPair.value);
end;
//Extend to Else
end;

function Tbc<A, B>.GetPairFunc(aa: A; bb: B): TKeyPair;
begin
result.KEY:=aa;
result.Value:=bb;
end;

← →
KSergey © (2009-05-12 11:07) [18]

> oxffff © (12.05.09 10:54) [17]
> Все хватает.

Читабельность - капец. перегруженная функция iif - ничем не хуже, но кроче.

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

← →
Alkid © (2009-05-12 11:10) [19]

Вообще, что бы "поставить" стиль, очень хорошо много читать исходники, написанные в нужном стиле. Но ещё лучше - устроиться работать в коллектив с сильными С++-программистами и просить, чтобы тебе там делали безжалостный code-reivew.

← →
Alex Konshin © (2009-05-12 11:16) [20]

> KSergey © (12.05.09 11:07) [18]
> > oxffff © (12.05.09 10:54) [17] > Все хватает. Читабельность
> - капец. перегруженная функция iif - ничем не хуже, но кроче.
> Потом, у тернарного оператора есть важная особенность, не
> реализуемая заменителями в виде функций: вычисляется только
> подходящая по условия часть.

Именно. И это очень важное отличие, о котором многие забывают (или не знают).

← →
oxffff © (2009-05-12 11:44) [21]

> KSergey © (12.05.09 11:07) [18]
> > oxffff © (12.05.09 10:54) [17]
> > Все хватает.
>
> Читабельность - капец. перегруженная функция iif - ничем
> не хуже, но кроче.

В [17] это case, if в [15].

> не реализуемая заменителями в виде функций: вычисляется
> только подходящая по условию часть.

В чем сложность?. Пример в студию

← →
Alex Konshin © (2009-05-12 11:48) [22]

item = array==null ? null : array[0];

← →
Юрий Зотов © (2009-05-12 12:01) [23]

Предвкушаю...

← →
oxffff © (2009-05-12 12:14) [24]

> Alex Konshin © (12.05.09 11:48) [22]
>KSergey © (12.05.09 11:07) [18]

А так не пробовали?

function TForm1.Ifthen<T>(Expression:boolean;const onTrue, onFalse: TFunc<T>):T;
var a:integer;
b:TFunc<boolean>;
begin
if Expression then exit(onTrue) else exit(onFalse);
end;

procedure TForm1.FormCreate(Sender: TObject);
var SomeArray:pinteger;
Value:integer;
begin
SomeArray:=nil;
Value:=Ifthen<integer>(SomeArray=nil, function : integer
begin
exit(0);
end
,
{$POINTERMATH ON}
function : integer
begin
exit(SomeArray[0]);
end
{$POINTERMATH OFF}
);
showmessage(inttostr(value));
end;

А в С++ нет замыканий.
И нет того чтобы ввели С# 4.0 под словом dynamic.
А в delphi есть.

← →
oxffff © (2009-05-12 12:14) [25]

> Юрий Зотов © (12.05.09 12:01) [23]

Приветствую Вас.

← →
KSergey © (2009-05-12 12:29) [26]

> oxffff © (12.05.09 12:14) [24]
> А так не пробовали?

теперь сравнить с кодом из [22] и плакать.

По смыслу: отсутствие тех или иных возможностей языка не влияет на качество итоговых программ. Совершенно. Хотя, конечно, длиной меряться помогает.

Но человека, привыкшего писать в идеологии одного языка - сразу видно, когда он пишет на другом свои первые опыты. Вполть до маразмов (но об этом не будем).

← →
oxffff © (2009-05-12 12:37) [27]

> KSergey © (12.05.09 12:29) [26]
> > oxffff © (12.05.09 12:14) [24]
> > А так не пробовали?
>
> теперь сравнить с кодом из [22] и плакать.

От чего плакать?
Я во всяком случае не заявляю о том, что это невозможно (ваш пост [18]).
Речь шла, что такого оператора нет. Я показал как сделать его самому.
То есть поступив конструктивно. Другой вопрос большей его записи.
Однако с введением "вывода типа" от записи
function : integer
begin
можно отказаться. Сократив технически до синтаксиса

Value:=Ifthen<integer>(SomeArray=nil, exit(0) ,
{$POINTERMATH ON}
exit(SomeArray[0]);
{$POINTERMATH OFF}
);

← →
oxffff © (2009-05-12 12:41) [28]

> Однако с введением "вывода типа" от записи

Точнее это даже здесь не нужно. Можно просто сократить запись для анонимных методов без параметров.

← →
Alkid © (2009-05-12 13:18) [29]

Что-то как-то от темы ушли :)
Кстати, этот топик - хорошая иллюстрация всей относительности высказывания, мол, настоящему программисту надо всего несколько дней, что бы освоить новый язык программирования :)

← →
KSergey © (2009-05-12 13:24) [30]

> oxffff © (12.05.09 12:37) [27]
> можно отказаться. Сократив технически до синтаксиса

А можно я сокращу до простого и понятного if then else? Спасибо.

← →
oxffff © (2009-05-12 13:28) [31]

> KSergey © (12.05.09 13:24) [30]
> > oxffff © (12.05.09 12:37) [27]
> > можно отказаться. Сократив технически до синтаксиса
>
> А можно я сокращу до простого и понятного if then else?
> Спасибо.

В том то и дело, мне лично не нравится вообще ? оператор.
Уж больно не читаемо - а если выражение сильно вложено ? в ?. То человеку нужно будет раскрутить левоассоциативные операторы от правоассоциативных. Поэтому ? оператор - это зло. IMHO.

← →
Anatoly Podgoretsky © (2009-05-12 13:30) [32]

> oxffff (12.05.2009 13:28:31) [31]

Не оператор ? зло, а Си :-)

← →
KSergey © (2009-05-12 13:31) [33]

> oxffff © (12.05.09 13:28) [31]
> Поэтому ? оператор - это зло.

лопатой убить не сложно, если че.
Про топор я и вовсе молчу.

← →
Alkid © (2009-05-12 14:04) [34]

> oxffff © (12.05.09 13:28) [31]
> В том то и дело, мне лично не нравится вообще ? оператор.
>
> Уж больно не читаемо - а если выражение сильно вложено ?
> в ?. То человеку нужно будет раскрутить левоассоциативные
> операторы от правоассоциативных. Поэтому ? оператор - это
> зло. IMHO.

Не согласен. Его синтаксис - не фонтан, и слишком много вложенных операторов ?: - это зло. Но условный оператор-выражение - это очень хорошая вещь, помогает писать в функциональном стиле там, где это возможно.

← →
oxffff © (2009-05-12 14:38) [35]

> Alkid © (12.05.09 14:04) [34]
>
> > oxffff © (12.05.09 13:28) [31]
> > В том то и дело, мне лично не нравится вообще ? оператор.
>
> >
> > Уж больно не читаемо - а если выражение сильно вложено
> ?
> > в ?. То человеку нужно будет раскрутить левоассоциативные
>
> > операторы от правоассоциативных. Поэтому ? оператор -
> это
> > зло. IMHO.
>
> Не согласен.

:). Приветствую тебя.
Я же добавил IMHO.

← →
Игорь Шевченко © (2009-05-12 14:39) [36]

> Поэтому ? оператор - это зло.

одна ласточка погоды не делает.
Да и то, смешно, право - программисты на паскале обсуждают синтаксис С, пусть даже с плюсами.

Вы б лучше APL или Lisp обсуждали - тоже смешно получится

← →
Alkid © (2009-05-12 14:54) [37]

> oxffff © (12.05.09 14:38) [35]
> :). Приветствую тебя.
> Я же добавил IMHO.

Привет :)
Ну ты своим имхом поделился, а я - своим :)

← →
Alkid © (2009-05-12 14:56) [38]

> Игорь Шевченко © (12.05.09 14:39) [36]
> одна ласточка погоды не делает.
> Да и то, смешно, право - программисты на паскале обсуждают
> синтаксис С, пусть даже с плюсами.
>
> Вы б лучше APL или Lisp обсуждали - тоже смешно получится

ИМХО, если программист хороший, то "программист" и "на дельфи" у него идут раздельно. "Программист" - это про фундаментальные знания, а "на дельфи" - это к конкретике, которая должна идти рядом с "на С", "на Lisp", "на ...". В такой постановке вопроса ничего смешонго не получается )

← →
Юрий Зотов © (2009-05-12 15:01) [39]

> Alkid © (12.05.09 14:56) [38]

Так на какое же "на ..." она должна идти? Можно с этого места чуть подробнее?
:o)

← →
Игорь Шевченко © (2009-05-12 15:03) [40]

Alkid © (12.05.09 14:56) [38]

Вот о степени "хорошести" программиста как раз и можно судить по высказываниям типа "foo есть безусловное зло и чем скорее сдохнут те, кто его использует, тем скорее мир станет светлее и чище".

> ИМХО, если программист хороший, то "программист" и "на дельфи"
> у него идут раздельно

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

А просто "хороший" программист, безотносительно языка, это, извини, сильно смахивает на сферического коня.

← →
Alkid © (2009-05-12 15:11) [41]

> Юрий Зотов © (12.05.09 15:01) [39]
>
> > Alkid © (12.05.09 14:56) [38]
>
> Так на какое же "на ..." она должна идти? Можно с этого
> места чуть подробнее?
> :o)

Только без пошлостей :)
Ну, там "..." - это метасинтаксическая переменная, определённая на множестве языков и технологий разработки :)

← →
Fast (2009-05-12 15:12) [42]

Что по мне, так после
> Юрий Зотов © (11.05.09 19:17) [6]
> Есть всего два стиля программирования - плохой и хороший.

все остальное (то есть все "впрыски" в эту ветку) своего рода какие-то испражнения
:)

← →
Alkid © (2009-05-12 15:24) [43]

> Игорь Шевченко © (12.05.09 15:03) [40]
> Вот о степени "хорошести" программиста как раз и можно судить
> по высказываниям типа "foo есть безусловное зло и чем скорее
> сдохнут те, кто его использует, тем скорее мир станет светлее
> и чище".

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

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

С этим согласен.

> А просто "хороший" программист, безотносительно языка, это,
> извини, сильно смахивает на сферического коня.

С этим тоже, в принципе, согласен, но с оговоркой, всё же.

Разные языки, технологии и парадигмы дают разные взгляды на программирование. Обобщение этих разных подходов даёт фундамент понимания программирования на более высоком уровне, чем просто применение тех или иных инструментов. При достаточной степени прокачанности это даёт возможность видеть принципиальные особенности языков и следующие из них design implications (по-русски знаю, как сказать, что бы передать "аромат" этого термина), даже не зная эти языки в деталях.

← →
oxffff © (2009-05-12 15:33) [44]

> Игорь Шевченко © (12.05.09 15:03) [40]
> Alkid © (12.05.09 14:56) [38]
>
> Вот о степени "хорошести" программиста как раз и можно судить
> по высказываниям типа "foo есть безусловное зло и чем скорее
> сдохнут те, кто его использует, тем скорее мир станет светлее
> и чище".

Вам вопросы в таком случае

1. В чем преимущество ? оператора перед обычным IF
2. Почему templates трансформируют в concepts по вашему

← →
KSergey © (2009-05-12 15:42) [45]

> oxffff © (12.05.09 15:33) [44]
> 1. В чем преимущество ? оператора перед обычным IF

Кратче.

> oxffff © (12.05.09 15:33) [44]
> 2. Почему templates трансформируют в concepts по вашему

Ну так и "алгоритмы+структуры данных=программы" уже "устаревшая" парадигма, и что? все меняется, мысля движется.

А вообще мне лично не очень понятно как эти вопросы связаны с приведенной цитатой.

← →
Игорь Шевченко © (2009-05-12 15:43) [46]

Alkid © (12.05.09 15:24) [43]

> design implications (по-русски знаю, как сказать, что бы
> передать "аромат" этого термина)

Я по-английски понимаю, спасибо.

> Разные языки, технологии и парадигмы дают разные взгляды
> на программирование. Обобщение этих разных подходов даёт
> фундамент понимания программирования на более высоком уровне,
> чем просто применение тех или иных инструментов

А что есть "программирование на более высоком уровне" ?
Вот если взять тот же MS - у него технологий, чтобы засорить мозги среднестатистическому программисту было придумано более чем достаточно. Возвращаясь к парадигмам - парадигмы на prolog и парадигмы на ассемблере обобщить как-то, на мой взгляд, не очень легко :) - какой тут может быть фундамент, я не совсем понимаю.

Кроме всего прочего, языков, парадигм и технологий за ~60 лет существования программирования было придумано немало, а придумывается еще больше. Все эти придумывания в основном преследовали и преследуют одну цель - управление сложностью решаемых проблем, но управляли они этой сложностью по-разному. Я несильно вижу смысл забивания головы программиста всяческими особенностями языков парадигм и технологий, на мой взгляд, кроме мешанины в голове это ни к чему не приведет и фундамент вряд ли построится...

← →
Игорь Шевченко © (2009-05-12 15:45) [47]

oxffff © (12.05.09 15:33) [44]

> 1. В чем преимущество ? оператора перед обычным IF

Даже комментировать не хочу.

> 2. Почему templates трансформируют в concepts по вашему

Не понял вопроса

← →
oxffff © (2009-05-12 15:48) [48]

> KSergey © (12.05.09 15:42) [45]
> > oxffff © (12.05.09 15:33) [44]
> > 1. В чем преимущество ? оператора перед обычным IF
>
> Кратче.

Мне как раз этот ответ Ваш и нужен был.
Зачем перегружать язык возможностью сделать что-то идентично двумя разными формами записи. Причем учитывая, что одна из этих форм записи небезопасно с точки зрения читабельности кода.
Зачем?

← →
oxffff © (2009-05-12 15:54) [49]

> Игорь Шевченко © (12.05.09 15:45) [47]
> oxffff © (12.05.09 15:33) [44]
>
>
> > 1. В чем преимущество ? оператора перед обычным IF
>
>
> Даже комментировать не хочу.

Я спрашию потому, что в своей практике не использовал его. Поэтому прошу снизойти и пояснить его преимущество по вашему кроме краткости.
В свою очередь прочитал
C++ Language Reference Conditional Operator: ? :
и других преимуществ не увидел.

← →
Alkid © (2009-05-12 15:55) [50]

> oxffff © (12.05.09 15:33) [44]
>
> Вам вопросы в таком случае
> 1. В чем преимущество ? оператора перед обычным IF

Тернарный оператор представляет собой выражение, в то время как обычный if - statement. В этом смысле они не взаимозаменяемые.

> 2. Почему templates трансформируют в concepts по вашему

Они их не трансформируют шаблоны в concepts, они консепты их добавляют к шаблонам. Мотивация - шаг в сторону design by contract, к декларативности. Шаблоны дают много свободы в compile-time (в частности, реализуют compile-time duck typing), но эта свобода оказалась не всегда полезна.

← →
oxffff © (2009-05-12 16:00) [51]

> > 2. Почему templates трансформируют в concepts по вашему
>
>
> Не понял вопроса

В новом стандарте планируют ввести Concepts - Templates with constraints.
Не кажется ли вам это есть стремление сделать язык более безопасным как с точки зрения type safety, так и с точки зрения readability?
То есть стремления сделать язык в какой степени более user friendly.

← →
AndreyV © (2009-05-12 16:02) [52]

> [48] oxffff © (12.05.09 15:48)
> Зачем перегружать язык возможностью сделать что-то идентично
> двумя разными формами записи.

Да совсем не идентично.

← →
Alkid © (2009-05-12 16:07) [53]

> Игорь Шевченко © (12.05.09 15:43) [46]
> А что есть "программирование на более высоком уровне" ?

Это понимание тех теоретических основ, выражением которых являются конкретные механизмы или технологии.

> Вот если взять тот же MS - у него технологий, чтобы засорить
> мозги среднестатистическому программисту было придумано
> более чем достаточно.

Ну, на MS зацикливаться не стоит. Хотя, скажем прямо, они сейчас разрабатывают очень интересные штуки. Например, только сегодня увидел, MS Axum - прототип языка, основанного на actor model.

> Возвращаясь к парадигмам - парадигмы на prolog и парадигмы
> на ассемблере обобщить как-то, на мой взгляд, не очень легко
> :) - какой тут может быть фундамент, я не совсем понимаю.

Очень просто - понимание того, что есть императивные языки и есть декларативные языки, какие у них есть свойства, достоинства и недостатки. Если человек понимает, что есть что, то в его картину мира прекрасно впишется и ассемблер и пролог. Если же он всю жизнь кроме ассемблера ничего не знал, ему Пролог покажется каббалистикой какой-то. Это парадокс Блаба.

> Кроме всего прочего, языков, парадигм и технологий за ~60
> лет существования программирования было придумано немало,
> а придумывается еще больше. Все эти придумывания в основном
> преследовали и преследуют одну цель - управление сложностью
> решаемых проблем, но управляли они этой сложностью по-разному.
> Я несильно вижу смысл забивания головы программиста всяческими
> особенностями языков парадигм и технологий, на мой взгляд,
> кроме мешанины в голове это ни к чему не приведет и фундамент
> вряд ли построится...

На самом деле за последние 60 лет ПРИНЦИПИАЛЬНО нового мало придумано и эти вещи прекрасно в голове укладываются. Вся та шелуха, которой сейчас много развелось, представляет собой лишь переупаковку основополагающих вещей в разных конфигурациях и под разными маркетинговыми соусами. Я сейчас навскидку не могу вспомнить чего-нибудь, что преподносилось с большой помпой в Джаве или С#, что было бы чем-то действительно ПРИНЦИПИАЛЬНО новым.

← →
oxffff © (2009-05-12 16:08) [54]

> Alkid © (12.05.09 15:55) [50]
>
> > oxffff © (12.05.09 15:33) [44]
> >
> > Вам вопросы в таком случае
> > 1. В чем преимущество ? оператора перед обычным IF
>
> Тернарный оператор представляет собой выражение, в то время
> как обычный if - statement. В этом смысле они не взаимозаменяемые.
>

Сути это не меняет. С точки зрения потока операций процессора это должен быть идентичный поток.

> > 2. Почему templates трансформируют в concepts по вашему
>
> Они их не трансформируют шаблоны в concepts, они консепты
> их добавляют к шаблонам. Мотивация - шаг в сторону design
> by contract, к декларативности. Шаблоны дают много свободы
> в compile-time (в частности, реализуют compile-time duck
> typing), но эта свобода оказалась не всегда полезна.

И в том и в другом случае ты не сможешь сделать над типом больше чем он тебе позволяет. Поэтому свободу это не ограничет. А вот указания место затыка для параметризованном классе укажет точно. Насколько я понял это основное их назначение.

← →
oxffff © (2009-05-12 16:10) [55]

> AndreyV © (12.05.09 16:02) [52]
> > [48] oxffff © (12.05.09 15:48)
> > Зачем перегружать язык возможностью сделать что-то идентично
>
> > двумя разными формами записи.
>
> Да совсем не идентично.

С точки зрения инструкций процессора?

← →
KSergey © (2009-05-12 16:18) [56]

> oxffff © (12.05.09 16:08) [54]
> С точки зрения потока операций процессора это должен быть идентичный поток.

И что? мне глубоко чихать на головную боль процессора. Меня своя гораздо более интересует.

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

← →
Игорь Шевченко © (2009-05-12 16:19) [57]

oxffff © (12.05.09 16:00) [51]

> В новом стандарте планируют ввести Concepts - Templates
> with constraints.
> Не кажется ли вам это есть стремление сделать язык более
> безопасным как с точки зрения type safety, так и с точки
> зрения readability?
> То есть стремления сделать язык в какой степени более user
> friendly.

В свое время на конференции SEC-R 2005 некий докладчик читал некий доклад. И все бы ничего, но существительные и глаголы в его докладе были транскрипцией с английского (ему приходилось говорить, а не писать) и понять его было довольно сложно. Я до сих пор жалею, что в материалах конференции не было текста этого доклала - как образец того, чего делать не надо.

Поэтому просьба - давай то же самое, только по-русски.

← →
palva © (2009-05-12 16:21) [58]

> Зачем?

Если серьезно, то конструкции ++, ?:, когда они появились, естественно были непривычными и поэтому нечитабельными. Но они позволяли создать более простой компилятор, такие конструкции гораздо легче оптимизировались, чем традиционная запись. В операторе a[<выражение>] = b ? x : y; код для вычисления <выражения> строится только один раз. А если записать это традиционным способом, то оптимизатор должен еще догадаться, что это одно и то же выражение, невзирая на то, что программист мог записать эти выражения немного по-разному. Если же выражение достаточно разветвленное, то и читабельность становится проблемной. Программист, читая традиционную запись и выверяя код в поисках багов, вынужден будет проверять идентичны ли эти записи.

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

То же можно сказать и про конструкцию ++.

← →
Alkid © (2009-05-12 16:22) [59]

> oxffff © (12.05.09 16:08) [54]
> Сути это не меняет. С точки зрения потока операций процессора
> это должен быть идентичный поток.

Дело в том, что языки программирования уже давно делаются не для процессоров, а для людей. По-этому то, что ты говоришь, уже не актуально, актуально то, как это люди воспринимают.

> А вот указания место затыка для параметризованном классе
> укажет точно. Насколько я понял это основное их назначение.

Абсолютно верно.

← →
oxffff © (2009-05-12 16:25) [60]

> Alkid © (12.05.09 15:55) [50]
>
> > oxffff © (12.05.09 15:33) [44]
> >
> > Вам вопросы в таком случае
> > 1. В чем преимущество ? оператора перед обычным IF
>
> Тернарный оператор представляет собой выражение, в то время
> как обычный if - statement. В этом смысле они не взаимозаменяемые.
>
>
>
> > 2. Почему templates трансформируют в concepts по вашему
>
> Они их не трансформируют шаблоны в concepts, они консепты
> их добавляют к шаблонам. Мотивация - шаг в сторону design
> by contract, к декларативности. Шаблоны дают много свободы
> в compile-time (в частности, реализуют compile-time duck
> typing),

Такого понятия нет. Duck typing не имеет отношение к concepts
Duck typing имеет отношение к полиморфизму отличному от наследования.

← →
Игорь Шевченко © (2009-05-12 16:27) [61]

Alkid © (12.05.09 16:07) [53]

> Это понимание тех теоретических основ, выражением которых
> являются конкретные механизмы или технологии.

Основы со времени Кнута вообще-то несильно изменились. А он их довольно популярно изложил.

> Очень просто - понимание того, что есть императивные языки
> и есть декларативные языки, какие у них есть свойства, достоинства
> и недостатки

И дальше что ? :) На свете есть много всего интересного, даже если программист будет знать, что есть языки таких классов, чем это ему может помочь ?

> На самом деле за последние 60 лет ПРИНЦИПИАЛЬНО нового мало
> придумано

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

← →
Alkid © (2009-05-12 16:30) [62]

> oxffff © (12.05.09 16:25) [60]
> Такого понятия нет. Duck typing не имеет отношение к concepts
> Duck typing имеет отношение к полиморфизму отличному от
> наследования.

Да ну? Скажи, чем отличаются дженерики в C# от шаблонов в C++ с точки зрения "потребительских свойств", т.е. не вдаваясь в детали реализации?

← →
oxffff © (2009-05-12 16:31) [63]

> palva © (12.05.09 16:21) [58]

Вот наконец реальный довод. Спасибо!

← →
Игорь Шевченко © (2009-05-12 16:32) [64]

palva © (12.05.09 16:21) [58]

> Если серьезно, то конструкции ++, ?:, когда они появились,
> естественно были непривычными и поэтому нечитабельными

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

(с)

← →
AndreyV © (2009-05-12 16:38) [65]

> [55] oxffff © (12.05.09 16:10)
> > Да совсем не идентично.
>
> С точки зрения инструкций процессора?

Может и инструкций для того первоначально и задуман, но теперь эта его сторона не актуальна. Но уже ответили.

← →
oxffff © (2009-05-12 16:41) [66]

> Alkid © (12.05.09 16:30) [62]

Различия отношения к duck typing не имеют.
А вот общее имеет отношение к duck typing,
И в том и другом случае нельзя вызвать неизвестный (несвязанный с типом)метод) и в том и другом случае.

Templates or generic types
Template functions or methods apply the duck test in a static typing context; this brings all the advantages and disadvantages of static versus dynamic type checking in general. Duck typing can also be more flexible in that only the methods actually called at run time need to be implemented, while templates require implementation of all methods that cannot be proven unreachable at
compile time.

Я понял что ты хотел сказать. Но придумать название этому я не знаю как. :))))

← →
palva © (2009-05-12 16:43) [67]

> Дело в том, что языки программирования уже давно делаются
> не для процессоров, а для людей

Ну я не для того, чтобы оспорить, - по большому счету я с вами согласен - но приведу такой пример. Когда 86 процессор изменился, в нем по-другому стала работать операция сдвига, типа стали учитываться только 5 младших битов в константе сдвига, то ведь изменился и C++. А что, взяли да внесли соответствующие изменения в стандарт языка. А вы говорите, для людей... Совсем недавно это было.

← →
Alkid © (2009-05-12 16:45) [68]

> Игорь Шевченко © (12.05.09 16:27) [61]
> Основы со времени Кнута вообще-то несильно изменились. А
> он их довольно популярно изложил.

Ну, вообщем-то да.

> И дальше что ? :) На свете есть много всего интересного,
> даже если программист будет знать, что есть языки таких
> классов, чем это ему может помочь ?

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

> Вообще-то придумано. И в основном для того, чтобы программирование
> из жреческого искусства сделать массовым ремеслом. Впрочем,
> возможно я не в курсе, что ты понимаешь под "принципиально"
> новым, если пояснишь, возможно дискуссия станет более плодотворной
> :)

Ну, например, какие свойства языка были сильно распиарены в C#? Это управляемый код, сборка мусора, "всё-есть-объект", интроспекция, динамичность (не типизации, а самого языка). Потом добавили лексические замыкания, linq, вывод типов. Все эти "новшества" - это хорошо забытое старое, поданное в красивой обёртке (про linq можно поспорить). Спору нет, .NET и C# получились очень удобной платформой и хорошим языком, но это всё не фундаментальные нововведения.

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

← →
Alkid © (2009-05-12 16:52) [69]

> oxffff © (12.05.09 16:41) [66]

Ну, вообщем, мы друг друга поняли.

Предлагаю ввести для этого дела термин "compile-time duck typing" или "static duck typing". Покрайней мере, пока не придумаем что-нибудь лучше :)

← →
Игорь Шевченко © (2009-05-12 16:52) [70]

Alkid © (12.05.09 16:45) [68]

> Это управляемый код, сборка мусора

Это не принципиально новое ? :) (Я имею в виду не относительно С#, а за 60 лет) ?

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

Я к чему - Hello, world, калькулятор, медиаплейер можно написать без замыканий, сборки мусора, объектов и т.п. А вот приличную корпоративную систему - уже труднее, хотя можно. Но невыгодно.

← →
Alkid © (2009-05-12 16:53) [71]

> palva © (12.05.09 16:43) [67]

Ну так а Вы чего хотите? :) С++ по нынешним меркам - это язык среднего уровня, а С - так вообще низкого :)

← →
Alkid © (2009-05-12 17:04) [72]

> Игорь Шевченко © (12.05.09 16:52) [70]
> Это не принципиально новое ? :) (Я имею в виду не относительно
> С#, а за 60 лет) ?

Когда его делали в LISP(1958-й год), это было новое. А когда в Java (1995-й год) - нет. Я это к чему - понимание этого дела а позволяет гораздо проще относиться к великому множеству технологий, которыми нас сейчас шумно бомбардируют крупные корпорации.

> Раньше были громоздкие программы на ассемблере (я не беру
> программирование в машинных кодах, это вообще до Адама было)
> - появились языки высокого уровня, где сложностью стало
> управлять на порядок легче (соответственно и задачи усложнились).
> Появились громоздкие программы на языках высокого уровня
> - соответственно, поднялся уровень языка, появилась та же
> сборка мусора, объекты, и т.п.

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

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

Вот тут крайне занимательная тема для осмысления - есть ли некий фундаментально-обусловленный "потолок" для повышения уровня абстракции и, если есть, насколько близко мы к нему подошли.

← →
Игорь Шевченко © (2009-05-12 17:11) [73]

Alkid © (12.05.09 17:04) [72]

> но и медленные программы на Lisp-е, в которых уже были сбора
> мусора, замыкания, метапрограммирование... :)

А вот поместить сборку мусора в императивный язык - это принципиально ? :)

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

← →
Alkid © (2009-05-12 17:23) [74]

> Игорь Шевченко © (12.05.09 17:11) [73]
> А вот поместить сборку мусора в императивный язык - это
> принципиально ? :)

А Lisp, кстати, позволяет писать вполне себе императивные программы :)

> А массовые языки - они все алголоподобные, как ни странно
> - то ли усваиваются лучше, то ли еще по каким причинам...

Всё просто - мэйнстрим программирования идейно рос от железа, которое было воплощением идей машины Тьюринга. Именно по-этому сейчас весь мэйнстрим императивный. При этом языки "от математики", тоже были со всеми их фитчами, но слабость железа не позволяла им быть реально универсальными языками. Сейчас наблюдает конвергенция, причём конвергениция "снизу" - алголоподобные языки начинают активно заимствовать у "академических" собратьев. Почему схождение идёт именно так - в принципе понятно, инерционность существующей инфраструктуры и мышления. Со всех сторон проще взять C# и постепенно довести его до Lisp, чем просто переключиться на Lisp.

← →
Alkid © (2009-05-12 17:25) [75]

P.S. Snobol мёртв, но его наследие живо :)
Я проследил следующую ветку: Snobol1..4 -> Icon -> Unicorn.

← →
Fast (2009-05-12 17:34) [76]

Естественно, понимая, что это не реально, но есть предложение:
Alkid ©
и
Игорь Шевченко ©
предложить продолжить это (даже не могу подобрать слово, прекрасно понимая, что Игорь Шевченко © затрет этот пост) в чате
:)

← →
Mystic © (2009-05-15 13:43) [77]

> Отсюда вопрос, как перестать писать в Паскаль стиле?

Для начала надо найти отличия Паскаль стиля от стиля C++. На первый взгляд это:

1. Поскольку объекты в C++ создаются в стеке, то они достаточно дешевые. Поэтому в C++ буквально на каждый чих объявляется свой собственный класс, и все методы, которые относятся к этому классу, перемещаются туда.

2. Стиль паскаля обычно исповедует try..finally конструкции. В C++ обычно такие ситуации стараются разруливать автоматическими деструкторами. Ну и использование всяких трюков на основе этого.

3. Для программиста на Pascal обычно возникают некоторые сложности при знакомстве с библиотеками а-ля STL или BOOST. Зачастую многие стандартные контейнеры программисты на паскале реализуют ручками. Больше в стиле C++ использовать итераторы, слабые указатели и т. п.

4. Шаблоны, множественное наследование. Программисты на паскале стараются этого избегать, и мало в курсе некоторых трюков с этим.

← →
Иа (2009-05-16 22:33) [78]

> Вам вопросы в таком случае
>
> 1. В чем преимущество ? оператора перед обычным IF

то что это оператор и может использоваться как оператор.

пример:

dbContext.Users.Select(u => new { u.Name, CompanyName = (u.Company != null) ? u.Company.Name : string.Empty)} );

← →
Mystic © (2009-05-17 00:14) [79]

> Иа (16.05.09 22:33) [78]

Iif в данном конкретном случае, был бы более читабелен, имхо. Или IsNull.

← →
ZeroDivide © (2009-05-17 00:53) [80]

> Но мы в затруднении, т.к. сейчас ты будешь программировать
> на С++ в паскаль стиле,
> а для нас это не приемлемо

А ты уверен, что ты хочешь у них работать?
Я б задумался.

А что, с вакансиями по Delphi, совсем туго стало?

← →
Германн © (2009-05-17 01:06) [81]

> ZeroDivide © (17.05.09 00:53) [80]
>
>
> > Но мы в затруднении, т.к. сейчас ты будешь программировать
> > на С++ в паскаль стиле,
> > а для нас это не приемлемо
>
>
> А ты уверен, что ты хочешь у них работать?
> Я б задумался.
>

+1
И не потому, что привержен стилю Дельфи. А потому что не привержен никаким стилям!
Но х.з. на что обратили внимание принимавшие примеры кода и собеседование. Может у них и есть веские причины отказать. Причины не фундаментальные, но для именно них - веские!

← →
Игорь Шевченко © (2009-05-17 01:46) [82]

> Iif в данном конкретном случае, был бы более читабелен,
> имхо. Или IsNull.

Iif нечитабелен вовсе.

Вместо Company != null можно написать !Company.IsUnnamed и IsNull уже не подходит.
А вот оператор ? : подходит во всех случаях. Его не зря придумали, вовсе не для того, чтобы засорить мозги рабочему классу.

← →
Mystic © (2009-05-17 02:20) [83]

Он то подходит во всех случаях, но часто мне приходилось втыкать в него, что же там происходит. Во-вторых, часто при изменении кода мне приходилось заменять ? : на обычный if и наоборот. А в одном случае было, что я за день в одном месте раза три одно на другое. В-третьих надо помнить его приоритет. А Iif предоставляет привычную функциональную запись. Так что это во многом это вопрос вкуса.

← →
Игорь Шевченко © (2009-05-17 02:58) [84]

Mystic © (17.05.09 02:20) [83]

> но часто мне приходилось втыкать в него, что же там происходит

Это нисколько ни умаляет достоинств оператора.

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

> В-третьих надо помнить его приоритет

Или взять в скобки, если приходится использовать такие конструкции, где приоритет непонятен при простом чтении.

Впрочем, программу на Фортране можно написать на любом языке программирования - было бы желание.

← →
Mer (2009-05-17 07:34) [85]

> [80] ZeroDivide © (17.05.09 00:53)
> А что, с вакансиями по Delphi, совсем туго стало?

Хм. С ними всегда туго было.
На Дельфи больших игр не делают.

← →
Alex Konshin © (2009-05-17 07:53) [86]

> Игорь Шевченко © (17.05.09 02:58) [84]
> Mystic © (17.05.09 02:20) [83] > но часто мне приходилось
> втыкать в него, что же там происходитЭто нисколько ни умаляет
> достоинств оператора.Повторюсь еще раз - функциональная
> запись и запись условного оператора с точки зрения "втыкабельности"
> являются настолько разными, что обуждать всерьез замену
> условного оператора функциональной записью есть сугубо бесперпективное
> занятие.

Я ещё раз повторю: между ?: и любыми попытками его эмулировать функциями всегда есть принципиальная разница потому, что в любой функции все аргументы вычисляются всегда. Если непонятно о чём я, то попытайтесь представить в фунциональной форме тот же пример, что я приводил (очень, кстати, частый случай употребления этого оператора):
item = array==null ? null : array[0];

← →
Mystic © (2009-05-17 11:24) [87]

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

Конечно я это знаю, но лично у меня такая ситуация возникает, мягко сказать, достаточно редко, чтобы принимать это во внимание.

← →
Григорьев Антон © (2009-05-17 15:15) [88]

> Alex Konshin © (17.05.09 07:53) [86]
> Я ещё раз повторю: между ?: и любыми попытками его эмулировать
> функциями всегда есть принципиальная разница потому, что
> в любой функции все аргументы вычисляются всегда.

Если функция будет встроенной, то за счёт compiler magic может и не вычисляться. А вот функциональная форма записи в данном случае действительно читабельнее будет.

← →
Игорь Шевченко © (2009-05-17 15:30) [89]

> А вот функциональная форма записи в данном случае действительно
> читабельнее будет.

а давай вообще все конструкции языка на функциональную запись переведем - чтобы врагам, упершим код, страшно стало.

← →
@!!ex © (2009-05-17 15:55) [90]

> [89] Игорь Шевченко © (17.05.09 15:30)

Так ведь функциональне языки прекрасно работают... и нет никаких проблем.

← →
AndreyV © (2009-05-17 16:24) [91]

> [88] Григорьев Антон © (17.05.09 15:15)
> Если функция будет встроенной, то за счёт compiler magic
> может и не вычисляться. А вот функциональная форма записи
> в данном случае действительно читабельнее будет.

Не ройдёт - стандарт говорит, что должно всё вычислится и это правильно, мало ли что там делается. Не делать же исключение для iif().

← →
AndreyV © (2009-05-17 16:27) [92]

> [91] AndreyV © (17.05.09 16:24)
> Не ройдёт - стандарт говорит, что должно всё вычислится
> и это правильно, мало ли что там делается. Не делать же
> исключение для iif().

Сам вижу грамматические ошибки.

← →
Игорь Шевченко © (2009-05-17 16:56) [93]

> Так ведь функциональне языки прекрасно работают... и нет
> никаких проблем.

с читабельностью ?
ассемблер тоже прекрасно работает

← →
Alkid © (2009-05-17 17:32) [94]

> Игорь Шевченко © (17.05.09 16:56) [93]
> с читабельностью ?
> ассемблер тоже прекрасно работает

Это вопрос привычки. Я не пропагандирую липсовский синтаксис (хотя у него есть свои плюсы), но есть язык и с весьма читаемым кодом. Например, тот же Хаскель. Или Эрланг.

← →
Игорь Шевченко © (2009-05-17 19:40) [95]

Alkid © (17.05.09 17:32) [94]

> Это вопрос привычки

Если кто не заметил, в сабже идет речь о Паскале и С

← →
Alkid © (2009-05-17 21:58) [96]

> Игорь Шевченко © (17.05.09 19:40) [95]
> Если кто не заметил, в сабже идет речь о Паскале и С

Сарказм не уместен. Тема расширилась, раз уж упоминаются функциональные языки и ассемблер :)

> Игорь Шевченко © (17.05.09 15:30) [89]
> а давай вообще все конструкции языка на функциональную запись
> переведем - чтобы врагам, упершим код, страшно стало.

Кстати, такие языки как Lisp и Prolog используют в высшей степени регулярные синтаксисы (у лиспа регулярнее, у пролога - выразительнее). Однако после первой адаптации (восновном у лиспа) его код прекрасно читается.

← →
Игорь Шевченко © (2009-05-17 22:26) [97]

Alkid © (17.05.09 21:58) [96]

> Сарказм не уместен

Вполне себе уместен, бо основная дискуссия развернулась в обсуждение "втыкабельности" оператора ? : для тех, кто привык программировать на паскале.

А наиболее читабельными языками являются, разумеется, perl и APL

← →
Германн © (2009-05-18 01:36) [98]

> Игорь Шевченко © (17.05.09 22:26) [97]
>
> Alkid © (17.05.09 21:58) [96]
>
>
> > Сарказм не уместен
>
>
> Вполне себе уместен, бо основная дискуссия развернулась
> в обсуждение "втыкабельности" оператора ? : для тех, кто
> привык программировать на паскале.
>
> А наиболее читабельными языками являются, разумеется, perl
> и APL

А для меня - ассемблер!
Но у меня и задачи другие. А вот про задачи - это иной вопрос!
:)

← →
KilkennyCat © (2009-05-18 01:53) [99]

Все херня. Похрен гдже, что и на чем. Истинному спецу похрен. Беда лишь в том, что истинный спец сродни художнику - олценят, когдва сдорхнешщь. Выбора два - делать денги, или делать качественно.

← →
KSergey © (2009-05-18 06:16) [100]

> KilkennyCat © (18.05.09 01:53) [99]
> Выбора два - делать денги, или делать качественно.

У всех "творцов" есть изъян: они жрать хотят. При этом часто не отвечая за наличие результата.
Так что должно быть и быстро, и качественно. "Вольные художники" - это раздолбаи.

← →
Alkid © (2009-05-18 09:14) [101]

> KilkennyCat © (18.05.09 01:53) [99]
>
> Все херня. Похрен гдже, что и на чем. Истинному спецу похрен.
> Беда лишь в том, что истинный спец сродни художнику - олценят,
> когдва сдорхнешщь. Выбора два - делать денги, или делать
> качественно.

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

← →
Mer (2009-05-18 10:24) [102]

> [101] Alkid © (18.05.09 09:14)

Вам попадаются клевые заказчики, если они это понимают!
Мне в основном попадаются:
"Надо сделать быстро, месяца за четыре. Сроки поджимают... Быстро! Быстро! Быстро!"
И это на проект, который в течении ближайших лет должен расширяться активно...
ВОт только БЫСТРО и КАЧЕСТВЕННО вещи не очень то совместимые.
Проект практически сделан.
По хорошему надо еще месяц два потратить на рефакторинг и вылизывание кода.
Вот только заказчик не хочет тратить время и деньги. Заказчик хочет РЕЗУЛЬТАТ.

← →
SPeller © (2009-05-18 11:06) [103]

Я когда писал на php постоянно использовал оператор ? и ничего, удобно местами. На дельфе не испытываю неудобств от его отсутствия. Что я делаю не так? :)

← →
Медвежонок Пятачок © (2009-05-18 11:13) [104]

Вот только заказчик не хочет тратить время и деньги. Заказчик хочет РЕЗУЛЬТАТ.

Какой направильный заказчик. Правильный заказчик должен хотеть не результат, а процесс.

← →
Alkid © (2009-05-18 11:13) [105]

> Mer (18.05.09 10:24) [102]

Заказная разработка вообще этим сильно страдает и там с этим труднее. Мне пришлось поплюхаться с этим на первой работе. Потом я работал в фирмах, которые делают коробочный софт, там положение дел зависит не от уровня понимания клиента, а от уровня понимания начальства. На предыдущей работе производство "быстро и абы как" в определённый момент стало чуть ли не официальной политикой, проводимой на уровне всего департамента разработки. Я оттуда почти сразу уволился :) Сейчас ситуация диаметрально противоположная - мой начальник очень много внимания уделяет качеству кода и дизайна.

← →
Медвежонок Пятачок © (2009-05-18 11:22) [106]

Проект практически сделан.
По хорошему надо еще месяц два потратить на рефакторинг и вылизывание кода.

Уже требуется рефакторинг свеженаписанного проекта?
Скорее требуется тест на профпригодность таких писателей.

← →
Alkid © (2009-05-18 11:27) [107]

> Медвежонок Пятачок © (18.05.09 11:22) [106]
> Уже требуется рефакторинг свеженаписанного проекта?
> Скорее требуется тест на профпригодность таких писателей.

Запросто. Таких ситуаций возникает вагон и тележка - требования поменялись, разработчик скосячил или не знал какой-то информации. Идеальный код с первого раза почти никогда не пишется. Зато потом с дважды-трижды переписанным кодом, вылизанным и обложенным юнит-тестами жить намного легче и дешевле, чем с тем, который write-only :)

← →
palva © (2009-05-18 11:27) [108]

> На дельфе не испытываю неудобств от его отсутствия. Что я делаю не так?

Надо было продолжать на php, тогда бы не было неудобств от его присутствия.

← →
Медвежонок Пятачок © (2009-05-18 11:31) [109]

Требования меняются часто.
Что это за архитектор, если каждый чих требует ни мало ни много а сразу оринга?

← →
Игорь Шевченко © (2009-05-18 11:37) [110]

Alkid © (18.05.09 11:27) [107]

> Идеальный код с первого раза почти никогда не пишется.

Все зависит от степени ясности решаемой задачи. Когда задача полностью ясна и осознана, то и код, чаще всего получается если не идеальный, то близкий к нему.

← →
Медвежонок Пятачок © (2009-05-18 11:49) [111]

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

← →
Игорь Шевченко © (2009-05-18 11:57) [112]

Медвежонок Пятачок © (18.05.09 11:49) [111]

Это уже от программиста зависит

← →
Anatoly Podgoretsky © (2009-05-18 12:05) [113]

> Mer (18.05.09 10:24) [102]

Да ради бога, если он хочет постоянно платить, а платить ему придется.

← →
Alkid © (2009-05-18 12:35) [114]

> Игорь Шевченко © (18.05.09 11:37) [110]
> Все зависит от степени ясности решаемой задачи. Когда задача
> полностью ясна и осознана, то и код, чаще всего получается
> если не идеальный, то близкий к нему.

Да, это так.
Абсолютно верное замечание.

← →
Медвежонок Пятачок © (2009-05-18 12:49) [115]

Качество кода как такового мало связано с качеством и детализацией поставленной задачи.

← →
Медвежонок Пятачок © (2009-05-18 12:55) [116]

Задача может быть поставлена крайне туманно и вообще не до конца поставлена. Например : "надо будет обрабатывать (как-то) входные файлы (где-то) и делать с ними что-то (потом скажу что)."

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

← →
@!!ex © (2009-05-18 12:55) [117]

> [115] Медвежонок Пятачок © (18.05.09 12:49)

Huh! Можно посмотреть примеры реализованных вами задач?
Просто ИМХО такое заявление говорит о практически полном отсутствии опыта в проектировании действительно сложных задача в сжатые сроки.
В первую очередь потому, что есть два варианта развития проекта:
1) Полная унивресальность. Этот подход ну никак не укладывается в разумные сроки.
2) Решение конкретной задачи с учетом возможных изменений в дальнейшем. Как показывает практика, предсказать на 100% что захочет заказчик в будущем - невозможно, а значит и заложить возможность тоже. Иногда пожелание заказчика очень сложно реализуемо в рамках разработанной архитектуры. А значит либо портим код, либо все переписываем. Второе исключается, потому что сроки сжаты. Вот и получаем на выходе код, который не плохо было бы отрефакторить.

P.S.
Естественно если мы делаем под копирку уже существующее решение, то там нет проблем предсказать чего хочет заказчик. А вот если делается уникальная система(в какой-то мере), то без рефакторинга перед релизом никак не обойтись.

← →
Медвежонок Пятачок © (2009-05-18 12:56) [118]

Просто ИМХО такое заявление говорит о практически полном отсутствии опыта в проектировании действительно сложных задача в сжатые сроки.
В первую очередь потому, что есть два варианта развития проекта:

Расслабся лучше.

← →
clickmaker © (2009-05-18 12:57) [119]

> как перестать писать в Паскаль стиле?

не нажимать шифт в начале идентификатора -)

← →
Медвежонок Пятачок © (2009-05-18 12:58) [120]

Вот и получаем на выходе код, который не плохо было бы отрефакторить.

Кто-то получает такой.
А кто-то получает совсем другой код.

← →
Alkid © (2009-05-18 13:02) [121]

> Медвежонок Пятачок © (18.05.09 12:56) [118]
> Расслабся лучше.

Нет-нет, не уходите от ответа, нам очень интересно послушать :)

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

Да не систему проектируем, очертания которой могут быть не известны до конца.
А код структурируем так, что его рефакторинг в первый день назначенного релиза не потребуется.

Ты же не систему рефакторишь, а код.

Любая универсальность, сделанная в расчете на возможные будущие изменения, есть зло по определению :)

> не нажимать шифт в начале идентификатора -)

Стилей написания в самом C++ до черта.

>Игорь Шевченко © (18.05.09 13:25) [123]
>Любая универсальность, сделанная в расчете на возможные будущие изменения, есть зло по >определению :)

Подписываюсь всеми четырьмя руками и ногами :)

> Игорь Шевченко © (18.05.09 13:25) [123]
> Любая универсальность, сделанная в расчете на возможные
> будущие изменения, есть зло по определению :)

:)
Вы очень часто рекомендуете книги к прочтению.
Вы их сами внимательно читаете?

oxffff © (19.05.09 11:57) [126]

> Вы их сами внимательно читаете?

В связи с каким именно моим словом возник подобный вопрос ?

> Игорь Шевченко © (19.05.09 12:05) [127]

> есть зло по >определению :)

В книгах которые предлагаете("навязываете") так и пишут?
Если это ваша точка зрения. Где аргументы?
И вам очень нравится глубочайший рефакторинг?

По моему глубокому убеждению. Универсальный обобщенный код является показателем мастерства программиста.

> Универсальный обобщенный код является показателем мастерства
> программиста

Возможно. Но программирование - прикладная наука, а не мастерство ради мастерства.

> clickmaker (19.05.2009 13:32:10) [130]

Иногда шаманство.

> oxffff © (19.05.09 13:18) [129]
> По моему глубокому убеждению. Универсальный обобщенный код
> является показателем мастерства программиста.

Или его желания самовыразиться ;)

> clickmaker © (19.05.09 13:32) [130]
> > Универсальный обобщенный код является показателем мастерства
>
> > программиста
>
> Возможно. Но программирование - прикладная наука, а не мастерство
> ради мастерства.

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

Alkid © (19.05.09 14:02) [132]

> Или его желания самовыразиться ;)

Я бы даже сказал - самовыпендриться.

oxffff © (19.05.09 13:18) [129]

> По моему глубокому убеждению. Универсальный обобщенный код
> является показателем мастерства программиста.

Это пройдет.

Есть набор правил, которыми рекомендуют руководствоваться программисты, чьи программы написаны давно и используются по сей день,
вот часть из них:

2. Правило ясности - ясность лучше, чем мастерство.

5. Правило простоты - необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо.

(с) Эрик Реймонд, "Искусство программирования для Unix"

> Универсальный обобщенный код является показателем мастерства
> программиста.

Универсальность во всем сродни проституции.

Любая программа на Delphi менее универсальна, чем само Delphi. Зато некоторый набор действий на ней выполнять проще и быстрее. Сам смысл разработки в том, чтобы теряя универсальность упрощать выполнение некоторых частных случаев.

> Mystic © (19.05.09 14:16) [135]

> Игорь Шевченко © (19.05.09 14:11) [134]

Мое стремление к универсальности вызвано не заботой о заказчике, а скорее заботой о себе. Зачем мне разрабатывать сходные решения для решения сходной задачи над другим набором данных. Ведь большинство программ, которые разрабатываются используют одни и те же решения в разном сочетании и вложенности. Так почему мы не облегчить себе работу и продумать структуру таких решений таким образом, чтобы все эти решения не только сочателись между собой, но и работали над произвольным набором типов. Ведь стремление к reusability не является чем то плохим.

> Игорь Шевченко © (19.05.09 14:11) [134]
> Alkid © (19.05.09 14:02) [132]
>
>
> > Или его желания самовыразиться ;)
>
>
> Я бы даже сказал - самовыпендриться.

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

>Mystic © (19.05.09 14:16) [135]
> Любая программа на Delphi менее универсальна, чем само Delphi.
>

Тут вы пытаетесь опровергать возможность написания языка на самом себе. По вашему любой другой язык будет хуже предыдущего.
;)

Так что к чему ваши слова я малось не понял. :)

oxffff © (19.05.09 14:39) [137]

Скорее говорит печальный опыт попытки повторного или хоть какого-то использования результатов деятельности программирующих "универсальные" решения

> Игорь Шевченко © (19.05.09 14:48) [139]

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

GOF паттерны, итераторы, MulticastDelegate(в противовес procedure of object) являются универсальными решениями.
Особенно MulticastDelegate какая мелочь этот связный список,
но какой качественный отрыв.

> oxffff © (19.05.09 14:33) [136]

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

> oxffff © (19.05.09 14:33) [136]
> Мое стремление к универсальности вызвано не заботой о заказчике,
> а скорее заботой о себе. Зачем мне разрабатывать сходные
> решения для решения сходной задачи над другим набором данных.
> Ведь большинство программ, которые разрабатываются используют
> одни и те же решения в разном сочетании и вложенности. Так
> почему мы не облегчить себе работу и продумать структуру
> таких решений таким образом, чтобы все эти решения не только
> сочателись между собой, но и работали над произвольным набором
> типов. Ведь стремление к reusability не является чем то
> плохим.

Я ничего против более обобщённых решений не имею, поскольку в обобщении основная сила программирования. Но, как показывает моя практика, недостаточно продуманное обобщённое решение доставляет несоизмеримо больше геморроя, чем конкретное решение. А продуманное обобщённое решение, помимо решения конкретной предметной задачи, требует так же тщательного анализа всего класса подобных задач, что может вылиться в гораздо бОльшие сроки разработки с естественно возникающим вопросом - окупятся ли эти вложения в будущем.

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

P.S. У Ашманова хорошо написано про универсальные решения.

Mystic © (19.05.09 14:16) [135]
А как же Дельфи написан на Дельфи? Предел того что можно сделать?

Игорь Шевченко © (19.05.09 14:48) [139]
А как же ОС и языки программирования? Или их подарил человечеству БОГ, так чисто поржать?

oxffff © (19.05.09 14:53) [140]

> GOF паттерны, итераторы, MulticastDelegate(в противовес
> procedure of object) являются универсальными решениями.
> Особенно MulticastDelegate какая мелочь этот связный список,
>
> но какой качественный отрыв.

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

Все универсальные решения надо документировать, без документации они практической ценности не несут, описывать условия применимости, описывать условия неприменимости, то есть, выполнять массу работы заранее, снижать понятность кода решения конкретной задачи, возможно, снижать производительность - а зачем ?

Я прошел через попытки универсализировать все и вся лет 15 назад. Надеюсь, благополучно.

> Mystic © (19.05.09 14:57) [141]
> > oxffff © (19.05.09 14:33) [136]

Есть большая разница между if и виртуальным методом.
В том что для If вам нужно изменять код универсального метода, а при использовании виртуального метода(контракта) вам этого делать не нужно.
Это проблема называется поверхностная универсализация.
Заключается в том, что сам универсальный алгоритм строится на вызове обобщенных методов которые работают для некоторого подмножества всего множества типов. Однако ничего не мешает обошить все множество типов в контракт и универсального алгоритму работать с контрактом. А типам реализовывать такой контракт и такой набор контрактов. И т.к далее ьолее верхние уровни. Да я не говорю что это просто. Сложно приходится затратить время на такое обобщение. Но это работает.

> oxffff © (19.05.09 14:53) [140]
> GOF паттерны,

Оффтопик (от оффтопика), но я придерживаюсь мнения, что паттерны есть проявление несовершенства языка.

> [146] oxffff © (19.05.09 15:08)

> Заключается в том, что сам универсальный алгоритм строится
> на вызове обобщенных методов которые работают для некоторого
> подмножества всего множества типов. Однако ничего не мешает
> обошить все множество типов в контракт и универсального
> алгоритму работать с контрактом. А типам реализовывать такой
> контракт и такой набор контрактов. И т.к далее ьолее верхние
> уровни. Да я не говорю что это просто. Сложно приходится
> затратить время на такое обобщение. Но это работает.

пусть ИИ этим занимается, когда будет изобретен )

к примеру, исходники Indy - отличная иллюстрация правильного, но непотребно запутанного кода.

> Игорь Шевченко © (19.05.09 15:07) [145]
> oxffff © (19.05.09 14:53) [140]
>
>
> > GOF паттерны, итераторы, MulticastDelegate(в противовес
>
> > procedure of object) являются универсальными решениями.
>
> > Особенно MulticastDelegate какая мелочь этот связный список,
>
> >
> > но какой качественный отрыв.
>
>
> Все хорошо в меру. Я стараюсь писать проще, даже если усложненное
> возможно когда-нибудь при каких-нибудь условиях может быть
> использовано. Тому есть несколько причин, первая - зачем
> писать больше сейчас, неизвестно, потребуется ли это в будущем,
> а вторая - зачем засорять мозги тому, кто будет работать
> с кодом после меня.

Зачем?

Давайте рассмотрим язык программирования Delphi. Мы же пишем вставлять одни конструкции в другие, передавать конструкциям разные типы вообщем сочетать их по разному. Такого рода решения для меня представляют ценность. Пусть и с потерей производительности.
А LINQ - это тоже же стремление к универсальности над контейнерами.
Разве это не примеры удачное решений?

> Alkid © (19.05.09 15:12) [147]
>
> > oxffff © (19.05.09 14:53) [140]
> > GOF паттерны,
>
> Оффтопик (от оффтопика), но я придерживаюсь мнения, что
> паттерны есть проявление несовершенства языка.

А как же например паттерн Посетитель?
Приведи пример языковой конструкции, которой нет в языках

> Тут вы пытаетесь опровергать возможность написания языка
> на самом себе. По вашему любой другой язык будет хуже предыдущего.

Нет, не хуже. Я не про языки программирования говорю.

Например, вы взялись за разработку системы бухгалтерского учета. Через некоторое время вы приносите заказчику компилятор и говорите, что с помощью этого языка программирования можно написать любую систему бухгалтерского учета. И еще много чего кроме этого. Так что это более универсально.

> oxffff © (19.05.09 15:20) [150]
> А как же например паттерн Посетитель?
> Приведи пример языковой конструкции, которой нет в языках

Multipe-dispatch.
Реализован в CLOS.

← →
Noctis (2009-05-19 15:25) [153]

Alkid © (19.05.09 15:12) [147]

>Оффтопик (от оффтопика), но я придерживаюсь мнения, что паттерны есть проявление несовершенства языка.

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

> А как же Дельфи написан на Дельфи? Предел того что можно
> сделать?

По универсальности предел. Если R[X] это множество задач, которые можно решить при помощи некоторой программы X, то если при помощи программы X написать программу Y, то R[Y] будет подмножеством R[X].

> Игорь Шевченко © (19.05.09 15:07) [145]
> oxffff © (19.05.09 14:53) [140]
> Все хорошо в меру

Так и я тоже придерживаюсь такоей точки зрения.

> Alkid © (19.05.09 15:24) [152]
>
> > oxffff © (19.05.09 15:20) [150]
> > А как же например паттерн Посетитель?
> > Приведи пример языковой конструкции, которой нет в языках
>
> Multipe-dispatch.
> Реализован в CLOS.

Да ты прав.

>
> Alkid © (19.05.09 15:24) [152]
>
> > oxffff © (19.05.09 15:20) [150]
> > А как же например паттерн Посетитель?
> > Приведи пример языковой конструкции, которой нет в языках
>
> Multipe-dispatch.
> Реализован в CLOS.

А шаблон Мост? :)

P.S. А oxffff то не знает.

> А как быть если продукт может являться надможеством другого
> продукта?

Это как-то опровергает то, что я написал?

> oxffff © (19.05.09 15:41) [159]
> А шаблон Мост? :)

Шаблон Мост, по сути, является своеобразной формой делегации, для сокрытия конкретного типа реализации. В CLOS это реализуется "по умолчанию", поскольку там используется динамическая типизация + объекты могут менять свой класс в течении времени жизни.

Типичный же сценарий непродуманной обобщённой разработки сводится к тому, что программисты без предварительного анализа долго делают "платформы" и "инфраструктуры", которые потом смогут "значительно упростить" разработку "будущих версий" (особо мечтательные программисты даже заявляют, что эту разработку "можно будет продавать как отдельный продукт"). В конечном итоге на получившемся монстрике пытаются сделать решение конкретной задачи и выясняется, что эту-то конкретную задачу на нём решать крайне неудобно, глючно и противно.
Я через такое проходил. Правда у меня это было только один раз.
Система получилось довольно клевая, и даже рабочая. Но для того чтобы она начала выигрывать перед специализированными системами на нее нужно потратить минимум год работы одного программиста. И она даже может продаваться как отдельный продукт... Вот только год на нее тратить у нас возможности нет, поэтому вполне рабочая и классная система лежит отдельно и вероятно в проекте мы от нее откажемся. А жаль.. получилось клево.

> Игорь Шевченко © (19.05.09 16:54) [163]
> Во-во

А всё потому, что люди недооценивают трудность построения обобщённых решений.

на одной из прошлых работ была задумка написать свою суперуниверсальную ERP. Классы, объекты, свойства, список доступа пользователей - все универсально и единообразно. Вплоть до того, что можно расширять список свойств объекта на лету, причем, без добавления полей в таблицы БД. Был даже встроенный недоязык: как бы конструктор операций из методов объектов с возможностью условных переходов и паскаль-подобный парсер выражений.
Задумка даже осуществилась.
Но работала очччень тормозно. Переборщили с сущностями и отношениями, и слишком запутали бизнес-логику.
Короче, система ушла в промышленную эксплуатацию частично. Причем, теми частями, которые менее ООП, а более приближены к эксель-подобным табличным системам.
Остальные части остались в основном как памятник универсальности, помноженной на нашу недальновидность -)

> Alkid © (19.05.09 16:37) [161]

У моста другое назначение. Трансформация одних вызовов в другие.
У объекта А есть метод B c сигнатурой S1.
Вызов B транслируется в вызов С с методом D c сигнатурой S2.

> @!!ex © (19.05.09 16:41) [162]

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

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

Вывод - делать обобщенные решения выгодно, когда есть, что обобщать. То есть, когда есть (или реально предвидится) некий немалый общий кусок.

> oxffff © (19.05.09 17:22) [166]
> У моста другое назначение. Трансформация одних вызовов в
> другие.
> У объекта А есть метод B c сигнатурой S1.
> Вызов B транслируется в вызов С с методом D c сигнатурой
> S2.

А мы точно не об Адаптере говорим?

Дополню - о Stateless адаптере :)

> Alkid © (19.05.09 17:25) [168]
>
> > oxffff © (19.05.09 17:22) [166]
> > У моста другое назначение. Трансформация одних вызовов
> в
> > другие.
> > У объекта А есть метод B c сигнатурой S1.
> > Вызов B транслируется в вызов С с методом D c сигнатурой
>
> > S2.
>
> А мы точно не об Адаптере говорим?

У моста трансляция вызова агрегату может также транслироваться в вызов с другой сигнатурой.Например

OuterObject.DrawRect ->
{aggregate.DrawLine();
aggregate.DrawLine();
aggregate.DrawLine();
aggregate.DrawLine()
}

Пример взят из книги Design Patterns.

P.S. Я надеюсь, что теперь я заставлю изменить твое мнение на менее категоричное. :)
Хотя не могу не согласиться с тобой, что часть из них действительно направлена на языковые пробелы(хотя имеем ли мы право так их называть.)
Уже подмеченный тобой visitor(аля double dispatch multi method), ну и знаменитая фабрика классов.
Но не все.

> oxffff © (19.05.09 18:49) [171]
> P.S. Я надеюсь, что теперь я заставлю изменить твое мнение
> на менее категоричное. :)
> Хотя не могу не согласиться с тобой, что часть из них действительно
> направлена на языковые пробелы(хотя имеем ли мы право так
> их называть.)
> Уже подмеченный тобой visitor(аля double dispatch multi
> method), ну и знаменитая фабрика классов.
> Но не все.

На самом деле я действительно слишком резко выразился. То, о чем говорил я, относится к тем паттернам, в которых программисту приходится писать много однотипного инфраструктурного кода. Хороший пример - Visitor. Другой хороши пример - Command или Strategy. Вообще, основная критика паттернов сводится к двум вещам:
1. Они восполняют пробелы в языке.
2. Они ничего не привносят существенного к простому принципу абстрагирования, издревле широко применявшемуся в программировании. Наиболее конкретные паттерны (Visitor) подпадают под первый пункт, более абстрактные (Bridge, Letter-in-envelope) под вторую (спорность этих утверждений осознаю в полной мере :) ).

> Они ничего не привносят существенного к простому принципу
> абстрагирования

Они приносят общую терминологию в программистские решения. И это хорошо, так как чем лучше программисты понимают друг друга, тем скорее наступит всеобщий вечный и немеряный рулез.

Как перестать программировать на С++ в Паскаль стиле? Найти похожие ветки