Кофе "Кактус"

Компоненты: (на одну порцию), кофе чёрный "АРАБИКА"-"Принц Лебо" - 1.5 ч.л., сахар - по вкусу, вода (холодная, не кипячённая) - 1 коф. чашечка.

1-й вариант.

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

2-й вариант.

В готовый кофе по лезвию ножа добавить коньяк по-вкусу.

>if (Matrix.add(Matrix.mul(a,b)).equals(e) вместо a*b = e

ты ещё скажи что исходные данные вместе с алгоритмами хардкодишь

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

Что за бред? И главное, откуда он взялся?

>Что за бред? И главное, откуда он взялся?

из фразы, мол бедные жабокодеры вынуждены писать всякие matrix.mul(matrix.add(a,b)) и т.д. =)

> Про жабку: Язык, в котором вместо == надо писать .equals из математики надо гнать ссаными тряпками.

Языки с переопределением операторов - зло. Ибо делают код плохо читаемым. А уж если к этому добавляются заковыристые правила приоритетов - сразу фтопку (это про плюсы).

> Языки с переопределением операторов - зло. Ибо делают код плохо читаемым.

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

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

> А уж если к этому добавляются заковыристые правила приоритетов - сразу фтопку (это про плюсы).

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

>отличаю нулевой вектор от нуля уже по контексту.

контекст может быть очень большой =)

> Хм, ну вот у меня как-то в голове хорошо укладывается, что "+" -- это не сложение, а операция, обозначенная оным знаком

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

Операторы очень здорово "обманывают" глаза. Это психология.

>> а обычно с гуем, сетью, обращением к другим программам, БД и прочеим.

>Ну если у Вас программа, которой остро необходимо всё это держать вместе и тесно переплетённым

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

> Нормальных языков нет, есть достаточно хорошие в каждой конкретной задаче.

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

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

А я напишу функцию square_root, которая будет вычислять кубический корень :D И что теперь?

Отсуствию перегрузки операторов нет никаких оправданий (по крайней мере, в языках более высокого уровня, чем Си++).

> А я напишу функцию square_root, которая будет вычислять кубический корень :D И что теперь?

Название функции - это базар, за который разработчик хоть как-то отвечает. Оператор ... это любая фигня за какой-то закорючкой (или двумя). Посмотрите на смысл операторов << в потоках в плюсах. Что они куда сдвигают? Они выбраны уважаемым БСТ только за способ связывания, И ВСЕ!

> Оператор ... это любая фигня за какой-то закорючкой (или двумя).

Ну речь-то шла о математических операторах.

> Посмотрите на смысл операторов << в потоках в плюсах. Что они куда сдвигают? Они выбраны уважаемым БСТ только за способ связывания, И ВСЕ!

Не всё. Они выбраны в том числе и за то, что туманно интуитивно отражают семантику "заслать эту хрень в поток вывода".

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

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

И? Оно вполне будет операцией "+", определённой на выбранном множестве.

> Операторы очень здорово "обманывают" глаза. Это психология.

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

> При этом у нее есть веское преимущество - она на одном языке.

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

Пример: Вроде вот всем ява хороша, а как начнёшь stax-ом генерировать xml-ку, так сразу приходится следить за тем, что writeEndTag написал стлько же раз, сколько и writeStartTag. Хотя простенький класс с поведением "в конструкторе открываем тэг -- в деструкторе закрываем", совмещённый с фишками времени жизни объекта a'la C++, сделал бы код значительно прозрачней. Хотя это всё равно будет плохо, ибо порядок освобождения памяти в рамках блока не определён.

> Пусть так. Но у одни языки "достаточно хороши" для более широких классов задач, чем другие языки.

Не исключено.

> Пример с оператором ==, который значит сильно разные вещи для ссылочных и примитивных типов, уже приводился.

Самое противное в нём, что он с целыми числами до 128 работает как equals. Забавно было наблюдать за коллегой, силившимся понять, почему программа кидает exception на 131 порции входных данных :)

> Они выбраны в том числе и за то, что туманно интуитивно отражают семантику "заслать эту хрень в поток вывода".

Мне кажется, Вы путаете причину и следствие. Это Вы привыкли к тому, что в плюсах оно так, поэтому для Вас оно теперь интуитивно.

> Оно вполне будет операцией "+", определённой на выбранном множестве.

А вот поведуйте мне, как Вы будете гарантировать (на уровне языка), допустим, ассоциативность переопределенной операции сложения?

> Потому они обычно и определяются "привычным" образом

А еще в программах бывают баги...

> А вот поведуйте мне, как Вы будете гарантировать (на уровне языка), допустим, ассоциативность переопределенной операции сложения?

Операция, обозначенная знаком "+" не обязана быть ассоциативной и коммутативной.

Более яркий пример: операция "*"(умножение) на множестве всех квадратных матриц не коммутативно в общем случае. И никому не мешало до сих пор :)

>> <<

> Это Вы привыкли к тому, что в плюсах оно так, поэтому для Вас оно теперь интуитивно.

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

Из FAQ:

>Гугль говорит, что это лечится с помощью "xauth -".

Ну, наверно, "xhost -"

В Fedora8, без лазанья руками в исходники tk (8.4), не заработает.

Re^3: 2gaa

>> 2. "Раскрыть всё", а лучше опцию, которая бы раскрывала всё по умолчанию.

> Уже есть в TODO, обдумывание ведётся.

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

Re^2: 2gaa

> В Fedora8, без лазанья руками в исходники tk (8.4), не заработает.

8.5 - тоже.

Или я что-то пропустил?

> Ну, наверно, "xhost -"

Спасибо, поправил.

> В Fedora8, без лазанья руками в исходники tk (8.4), не заработает.

Там что-то намудрили с xhost?

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

Re^2: 2gaa

> Там что-то намудрили с xhost? 

[krege@bear ~]$ xhost
access control enabled, only authorized clients can connect
SI:localuser:krege

Вот из-за второй строчки и проблема. В багзиле есть запись по этому поводу, разработчики
сказали, что вторая строка - это фича, использование которой им очень нужно и важно,
например, для случаев расположения ~ на nfs (почти цитата). Tk на неё обижается, так как
она 1) сделана не в стандартном виде, 2) ещё что-то, не помню.

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

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

Ьыло бы хорошо. То, что я сделал иначе чем грязным хаком не назовёшь. Это если литературно.