провокация ;)
Sergei Riaguzov
Hу и что ви таки говорите что Unix платформа для программирования? В ней же
даже нету редактора кода. Посмотрим например на такую важную и полезную функцию
как автодополнение кода для объектных языков. Возьмем C++. Так называемые
редакторы кода - умеют ли они эту функцию? Посмотрим-ка..
1. Kdevelop - можно заимпортить рекурсивно /usr/include но это ничего не даст.
cout.[F8] не работает. Возможно следует вклепать всю эту муйную из /usr/include
прямо в проект - но проетистировать вам это не удастся - скорее всего это чудо
просто раньше упадет.
2. Anjuta. Оно еще у вас не упало?.. Сейчас упадет..
3. vim.. Автокомплета нет. Скрипт cppcomplete не работает, что сам автор пишет
на своей страничке (не делает парсинга кода, соотв. все забавы с наследованием
идут лесом).
3. emacs. Та же песня. Intellisense из cedet не работает правильно. xrefactory
за 400$ кстати тоже. После некоторого перетрахивания /usr/include/c++ и
создания из него своей директории и подключения ее в .xrefc кое-что делает вид
что работает, но достаточно например написать string s; s.[F8] или vector<int>
v; v.[F8] и удивиться..
4. Eclipse CDT. Говорят теже песни. Автокомплит то работает то нет. Кроме того
говорят он ЕЩЕ медленнее чем просто emacs.
Hу и?
Sergei Riaguzov
27 Sep 05 05:04, I wrote to you:
SR> 4. Eclipse CDT. Говорят теже песни. Автокомплит то работает то нет.
SR> Кроме того говорят он ЕЩЕ медленнее чем просто emacs.
s/чем просто emacs/чем просто eclipse/
Mike Gorchak
SR>> 4. Eclipse CDT. Говорят теже песни. Автокомплит то работает то нет.
SR>> Кроме того говорят он ЕЩЕ медленнее чем просто emacs.
SR> s/чем просто emacs/чем просто eclipse/
CDT это плагин. На j9 работает быстро, памяти жрет умеренно.
With best regards, Mike Gorchak. E-mail: mi...@malva.com.ua
Alexander Timoshenko
> Hello All.
>
> Hу и?
Visual SlickEdit.
--
gonzo
Andriy Beregovenko
27 сентября 2005 05:04, Sergei Riaguzov писал All:
SR> Hу и что ви таки говорите что Unix платформа для программирования? В
SR> ней же даже нету редактора кода. Посмотрим например на такую важную и
SR> полезную функцию как автодополнение кода для объектных языков. Возьмем
SR> C++. Так называемые редакторы кода - умеют ли они эту функцию?
SR> Посмотрим-ка..
------------------------[ линия отреза ]-------------------------
/цитата сокращена/
------------------------[ линия отреза ]-------------------------
SR> Hу и?
А еще там Ctrl+F9 не работает :) А еще F5... И в нагрузку в меню Compile не
хватает Parameters... Да и воопще что за беспридел в меню Help нету пункта
Search in MSDN... кашмар просто, истинно платформа для детей котор?е пишут
вредные скрипты... Вот уже ж ....
А воопще то следует задуматься,а надо ли автокомплит? Вот не поверишь, который
год програмирую, до сих пор не привык к автокомплиту. Hо это же конечно только
мои половые болезни... Единственное что немешало бы это hint с типами
параметров, но и это нужно в принципе как грится "временно", до 3-4-го
использования... А воопще толковый програмист знает какая функция с какими
параметрами и как пишется(про заглавные и строчные буквы)... Даже я
безтолковый, и то помню почти все что пользую...
P.S. Провокация не удалась :) Это не есть тема для споров, это просто
несравнимо... Кому как нравится, так и програмирует, включая IDE...
Bye Sergei!
... Кыс-Кыс... Иди сюда моя Кыыыыса....
Victor Wagner
wrote:
SR> Hello All.
SR> Hу и что ви таки говорите что Unix платформа для
SR> программирования? В ней же даже нету редактора кода.
SR> Посмотрим например на такую важную и полезную функцию как
SR> автодополнение кода для объектных языков. Возьмем C++. Так
SR> называемые редакторы кода - умеют ли они эту функцию?
SR> Посмотрим-ка..
А на нормальных языках писать не пробовали?
Да, я знаю, что C++ многие очень любят. Но объектно-ориетированное
прогроаммирование в нем хуже SmallTalk-а или Java , низкоуровневое - хуже
Eiffel-я или pure C, а все вместе - такая каша, что ни один редактор с
нормальным
completion не справляется, и от силы 10-15 программистов в мире
справляются с удержанием логики проекта в головне
--
Богу тоже отнюдь не возбраняется не верить в людей. -- А Громов.
Valentin Nechayev
SR>> программирования? В ней же даже нету редактора кода.
SR>> Посмотрим например на такую важную и полезную функцию как
SR>> автодополнение кода для объектных языков. Возьмем C++. Так
SR>> называемые редакторы кода - умеют ли они эту функцию?
SR>> Посмотрим-ка..
VW> А на нормальных языках писать не пробовали?
VW> Да, я знаю, что C++ многие очень любят. Но объектно-ориетированное
Ну вообще-то держать в памяти, как называется метод добавления
данных в очередном собственном объекте - Insert, Add или Append -
является проблемой независимо от языка. (Я не говорю про
контейнеры - это случай более простой.) И неумение понимать C++ -
не может быть обосновано только заковыристостью C++. Хотя если
через его ненужность большинству программистов под Unix - вполне
пригодное объяснение.
Впрочем, "важность" и "полезность" автодополнения, безусловно,
надумана: оно имеет существенный смысл только в случае венгерской
нотации и прочих декораций, когда набрать все эти lpsz без
опечатки становится проблемой. Это всё тот же выбор между меню как
средством "опережающего вопроса" и прямым набором: давать выбор
между вариантами набора в виде меню - имеет смысл или когда методы
(поля) не помнятся совсем, или когда их легче выбрать, чем нажать
несколько кнопок на клавиатуре.
Венгерская же нотация, которая является в виндовом мире основным
стимулом автодополнения, не имеет никакой C++ специфики: это
специфика и не C++ и не Windows, а определённого стиля мышления,
который был, в частности, рассчитан на отсутствие поддержки среды(!)
Получается парадоксальное "короткое замыкание":
1) Сначала придумали венгерку как средство включить в имя объекта
(в широком смысле) данные о его типе и использовании, рассчитывая
при этом в значительной мере на средства периода компиляции: за
соответствием декорации имени и режима использования следит
программист, а за наличием таких имён в декларации - компилятор,
уже на этапе компиляции, а не написания;
2) Затем из-за неудобства набора имён венгеркой форсировали
автодополнение как черту Visual C++ и тому подобных средств;(((
И это вместо того, чтобы устранить ненужные декорации и тем самым
резко сократить необходимость автодополнения...
-netch-
Victor Wagner
>>>>Victor Wagner wrote:
VW>>А на нормальных языках писать не пробовали? Да, я знаю,
VW>>что C++ многие очень любят. Но объектно-ориетированное
VN>Ну вообще-то держать в памяти, как называется метод
VN>добавления данных в очередном собственном объекте - Insert,
VN>Add или Append - является проблемой независимо от языка. (Я
Вообще-то если знать английский язык на уровне "Читать Киплинга по
вечерам с целью отдыха от компьютеров", между этими тремя словами есть
четкая семантическая разница. Более того Insert и Append у очень многих
объектов присутствуют оба. Выполняя РАЗНЫЕ действия.
Да, конечно, грамотное проектирование интерфейса собственного объекта,
это задача не из простых. Но если она решена, то использовать insert или
append - очевидно из контекста.
Хитрость в том, что C++ - это очень хороший и мощный язык
программирования. При условии, что вышеописанную задачу грамотного
проектирования интерфейса программист способен выполнять на
подсознательном уровне. Причем так, что понять эту спецификацию все его
коллеги по команде способны на том же подсознательном уровне.
К сожалению, таких программистов явное меньшинство.
А в случае отсутствия грамотного проектирования, C++ предоставляет куда
более длинную веревку для повеситься, чем plain old C или Java.
Вот того, кто засунул C++ в учебные программы младших курсов вузов,
точно стоило бы повесить.
VN>не говорю про контейнеры - это случай более простой.) И
VN>неумение понимать C++ - не может быть обосновано только
VN>заковыристостью C++. Хотя если через его ненужность
VN>большинству программистов под Unix - вполне пригодное
VN>объяснение.
Ну здесь естественно, имеется некоторое количественное соотношение между
количеством рабочих часов, которые нужно потратить на то, чтобы эта фича
заработала и количеством часов, которые она сэкономит, когда заработает.
А последнее подсчитывается с учетом приведенных тобой других способов
ускорения набора кода.
--
Andrey Sverdlichenko
> Hу и что ви таки говорите что Unix платформа для программирования? В ней же
> даже нету редактора кода. Посмотрим например на такую важную и полезную функцию
> как автодополнение кода для объектных языков. Возьмем C++.
Она неважная, но slickedit ее умеет. Но плохая реализация vi mode его
погубит.
Sergei Riaguzov
27 Sep 05 09:44, you wrote to me:
SR>> Hу и?
AB> А воопще то следует задуматься,а надо ли автокомплит? Вот не поверишь,
AB> который год програмирую, до сих пор не привык к автокомплиту. Hо это
AB> же конечно только мои половые болезни... Единственное что немешало бы
AB> это hint с типами параметров, но и это нужно в принципе как грится
AB> "временно", до 3-4-го использования... А воопще толковый програмист
AB> знает какая функция с какими параметрами и как пишется(про заглавные и
AB> строчные буквы)... Даже я безтолковый, и то помню почти все что
AB> пользую...
Это отмазки. ;)
AB> P.S. Провокация не удалась :) Это не есть тема для споров, это просто
AB> несравнимо... Кому как нравится, так и програмирует, включая IDE...
В том-то и дело что это неправда. IDE для Unix нету. Unix типа сам IDE и все
такое (с). Hо по сравнению с тем же MS VS для C++ IDE без автокомплита с
emacs'ом выглядящем как писк моды 80'ых годов (я про менюшки и прочее), вимом в
котором надо раскорячивать пальцы чтобы вводить команды и глючными прочими ide.
:) То есть вот эта фраза: "Кому как нравится, так и програмирует, включая
IDE..." вопиюще неправдива, потому что выбора нету. :)
Sergei Riaguzov
27 Sep 05 09:52, you wrote to me:
SR>>> 4. Eclipse CDT. Говорят теже песни. Автокомплит то работает то
SR>>> нет. Кроме того говорят он ЕЩЕ медленнее чем просто emacs.
SR>> s/чем просто emacs/чем просто eclipse/
MG> CDT это плагин. Hа j9 работает быстро, памяти жрет умеренно.
Что такое j9?
Sergei Riaguzov
27 Sep 05 10:36, you wrote to me:
>> Hу и?
AT> Visual SlickEdit.
Говорят оно там такое же убогое.
Alexander Timoshenko
предыдущих ораторов - фича не такая уж и нужная.
--
gonzo
Max Khon
27 Sep 05 10:31, you wrote to Victor Wagner:
VN> Венгерская же нотация, которая является в виндовом мире основным
VN> стимулом автодополнения, не имеет никакой C++ специфики: это
VN> специфика и не C++ и не Windows, а определённого стиля мышления,
VN> который был, в частности, рассчитан на отсутствие поддержки среды(!)
не согласен. автодополнение сильно ускоряет процесс разработки, особенно в
большом развесистом проекте, когда число строк измеряется миллионами.
вообще говоря, автодополнение по своей сути является неким разумным дополнением
к той функциональности, которую предоставляет ctags. а венгерская нотация тут
совсем непричем.
/fjoe
Mike Gorchak
SR>>>> 4. Eclipse CDT. Говорят теже песни. Автокомплит то работает то
SR>>>> нет. Кроме того говорят он ЕЩЕ медленнее чем просто emacs.
SR>>> s/чем просто emacs/чем просто eclipse/
MG>> CDT это плагин. Hа j9 работает быстро, памяти жрет умеренно.
SR> Что такое j9?
IBM's J9 virtual machine.
Andriy O. Beregovenko
> А воопще толковый програмист
> AB> знает какая функция с какими параметрами и как пишется(про заглавные и
> AB> строчные буквы)... Даже я безтолковый, и то помню почти все что
> AB> пользую...
> Это отмазки. ;)
отключен(а хинты нет :]). Опять же, это наверное я такой больной... но
это всего лишь мое ИМХО... Кстати мои знакомые (которые програмят)
почему то автокомплит в ВЦ++ отключают таки.. это наверное груповая
болезнь...
> AB> P.S. Провокация не удалась :) Это не есть тема для споров, это просто
> AB> несравнимо... Кому как нравится, так и програмирует, включая IDE...
> В том-то и дело что это неправда. IDE для Unix нету. Unix типа сам IDE и все
> такое (с).
Не совсем так, это не ИДЕ, это удобная для разработки среда... особенно
не может не порадовать система помощи (man, info)
> Hо по сравнению с тем же MS VS для C++ IDE без автокомплита с emacs'ом
Несравнимо... А ВЦ++ умеет подсвечивать пхп-код? а джаваскрипт?? а
хтмл???а конфиги кваки контры?? (Это первое что упало в мысль, про
остальное я молчу)
> выглядящем как писк моды 80'ых годов (я про менюшки и прочее),
не в менюшках сила ИДЕ, а в его юзабельности...
> вимом в котором надо раскорячивать пальцы чтобы вводить команды
Спорим я поправлю текст С++ програмы быстрее в виме, чем ты в ВЦ++ ИДЕ ???
> и глючными прочими ide. :) То есть вот эта фраза: "Кому как нравится, так
> и програмирует, включая IDE..." вопиюще неправдива, потому что выбора нету. :)
Выбор есть всегда... Другое дело когда по глючности тормознутости и
прочим параметрам "неюзабельности" ИДЕ типа КДЕВЕЛОП, ВЦ++ ИДЕ
моментально уходят в сад...Да тяжело выбрать ИДЕ, но главное что бы
потом в нем толково работалось, и что бы ИДЕ не отвлекало и не тормозило
работу, а наоборот....
--
Andriy
Mike Gorchak
AOB> Это не отмазки, это нормально. У меня в делфи например автокомплит
AOB> отключен(а хинты нет :]). Опять же, это наверное я такой больной... но
AOB> это всего лишь мое ИМХО... Кстати мои знакомые (которые програмят)
AOB> почему то автокомплит в ВЦ++ отключают таки.. это наверное груповая
AOB> болезнь...
Ну скажем в builder (так как была умопянута delphi) автокоплит превращался в
парусекундный ступор, на vc++ то же самое на медленных машинах с
относительно малым количеством памяти. Я не знаю ни одного билдерятника,
который использует автокомплит :)
Vadim Goncharov
On Tue, 27 Sep 2005 07:31:11 +0000 (UTC); Valentin Nechayev wrote about 'Re: провокация ;)':
VN> Впрочем, "важность" и "полезность" автодополнения, безусловно,
VN> надумана: оно имеет существенный смысл только в случае венгерской
VN> нотации и прочих декораций, когда набрать все эти lpsz без
VN> опечатки становится проблемой. Это всё тот же выбор между меню как
VN> средством "опережающего вопроса" и прямым набором: давать выбор
VN> между вариантами набора в виде меню - имеет смысл или когда методы
VN> (поля) не помнятся совсем, или когда их легче выбрать, чем нажать
VN> несколько кнопок на клавиатуре.
VN> Венгерская же нотация, которая является в виндовом мире основным
VN> стимулом автодополнения, не имеет никакой C++ специфики: это
[...skip...]
VN> И это вместо того, чтобы устранить ненужные декорации и тем самым
VN> резко сократить необходимость автодополнения...
Нет. Автодополнение никоим образом не привязано к венгерской нотации и
[Visual] C/C++. Оно нужно затем же, зачем и в шелле - резко ускорить
набор (я поначалу все порывался в Delphi Tab нажать). Вот пример кода:
if FndWnd(UnpackedFrame.FromNick)=-1 then
begin
NewWnd(UnpackedFrame.FromNick, True);
ChatMainForm.WndCBoxLabel.Font.Color:=clRed; //indicate new wnd
end;
PutWnd(UnpackedFrame.FromNick, s);
Как видно, венгерской нотацией здесь и не пахнет (кроме системной
константы), читабельность кода высокая (что критично для больших
проектов), но набрать это быстро (в несколько раз!) можно только с
автодополнением. Причем вываливаемое меню сортирует переменные опять же
по контексту, что ускоряет выбор.
P.S. А крики "оно нам и не надо" - рассуждения в стиле "зелен виноград".
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Andrey Ladugin
27 Сен 05 в 15:11, Andriy O. Beregovenko писал Sergei Riaguzov следующее:
AB> Hе совсем так, это не ИДЕ, это удобная для разработки среда...
AB> особенно
AB> не может не порадовать система помощи (man, info)
можно ли как-то проводить поиск по всем man, info?
что-то типа GUI - морды объединения их в единую MSDN :)
Андрей
Valentin Nechayev
>>> Vadim Goncharov wrote:
VG> Нет. Автодополнение никоим образом не привязано к венгерской нотации и
VG> [Visual] C/C++.
Я не говорил, что оно привязано. Я говорил, что это один из
наиболее мощных стимулов к использованию автодополнения, хоть и
косвенный. А где оно впервые появилось - тут уже без разницы.
VG> Оно нужно затем же, зачем и в шелле - резко ускорить
VG> набор (я поначалу все порывался в Delphi Tab нажать). Вот пример кода:
VG> if FndWnd(UnpackedFrame.FromNick)=-1 then
VG> begin
VG> NewWnd(UnpackedFrame.FromNick, True);
VG> ChatMainForm.WndCBoxLabel.Font.Color:=clRed; //indicate new wnd
VG> end;
VG> PutWnd(UnpackedFrame.FromNick, s);
VG> Как видно, венгерской нотацией здесь и не пахнет (кроме системной
VG> константы), читабельность кода высокая (что критично для больших
VG> проектов), но набрать это быстро (в несколько раз!) можно только с
VG> автодополнением. Причем вываливаемое меню сортирует переменные опять же
VG> по контексту, что ускоряет выбор.
А что за сортировка по контексту?
VG> P.S. А крики "оно нам и не надо" - рассуждения в стиле "зелен виноград".
Ну я лично про "не надо" не кричал:) Его необходимость не
настолько высокая как многим представляется - вот это факт.
Конечно, удобнее было бы с ним.
А если вводить какой-то code browser с его возможностями, то кроме
автодополнения потребуется ещё много чего и, возможно, раньше чем
автодополнение. Например, я часто использую старый юниксовый приём
с префиксом поля в структуре зависящим от имени структурного типа:
искать wc_flags или mco_flags в большом куске кода (а особенно в
нескольких файлах) значительно проще, чем искать просто flags и
отделять затем по контексту, к какому из 10-20-500 структурных
типов этот flags относится (что в случае конструкций типа
vp->vx_op->vxo_parse->vop_convert->mco_flags превращается в
медленную китайскую пытку). Толковый code browser мог бы
автоматизировать эту работу, выполнив операцию "grep по таким-то
файлам всех строк где используется mail_convert_operation::flags".
И мне лично это на порядок важнее автодополнения.
-netch-
Vadim Goncharov
On Wed, 28 Sep 2005 06:01:07 +0000 (UTC); Valentin Nechayev wrote about 'Re: провокация ;)':
VG>> Нет. Автодополнение никоим образом не привязано к венгерской нотации и
VG>> [Visual] C/C++.
VN> Я не говорил, что оно привязано. Я говорил, что это один из
VN> наиболее мощных стимулов к использованию автодополнения, хоть и
VN> косвенный. А где оно впервые появилось - тут уже без разницы.
Я бы поспорил, что такой уж мощный. В венгерской нотации в коде обычно много
переменных с одинаковым венгерским префиксом, а сами префиксы нередко
весьма crunched так, что их по одной букве не автодополнить. В таких
случаях венгерская нотация начинает снижать эффективность автодополнения :)
VG>> Оно нужно затем же, зачем и в шелле - резко ускорить
VG>> набор (я поначалу все порывался в Delphi Tab нажать). Вот пример кода:
VG>> if FndWnd(UnpackedFrame.FromNick)=-1 then
VG>> begin
VG>> NewWnd(UnpackedFrame.FromNick, True);
VG>> ChatMainForm.WndCBoxLabel.Font.Color:=clRed; //indicate new wnd
VG>> end;
VG>> PutWnd(UnpackedFrame.FromNick, s);
VG>> Как видно, венгерской нотацией здесь и не пахнет (кроме системной
VG>> константы), читабельность кода высокая (что критично для больших
VG>> проектов), но набрать это быстро (в несколько раз!) можно только с
VG>> автодополнением. Причем вываливаемое меню сортирует переменные опять же
VG>> по контексту, что ускоряет выбор.
VN> А что за сортировка по контексту?
Ну вот в примере выше, допустим. Набираю := и жму ^Space - вываливается
менюшка с большущим списком (потому что может потребоваться присвоить
значение поля какого-нибудь объекта, а сначала надо набрать его имя,
поэтому они там все присутствуют). Но оно отсортировано правильным
образом - сначала наиболее подходящие по типу переменные/константы,
причем из тех которые определил я (порядок вложенности scope). Это
часто приводит вообще к замечательным последствиям: допустим, в текущую
процедуру передана строка с длинным именем, а в данной строке кода надо
позвать функцию, один из аргументов которой строка:
PutWnd(UnpackedFrame.FromNick, _); // _ - тут курсор
(В это время, кстати, всплыл хинт с аргументами). Я жму ^Space и первой
же позицией будет это единственное имя UserMsgText, так что я сразу жму
Enter. Т.е. вместо 11 нажатий - только 3, не пришлось листать список.
Кстати, автодополнение автоматически исправляет регистр набранного, что
в каком-нибудь Паскале просто повышает читабельность, а в Си жизненно
необходимо :)
VG>> P.S. А крики "оно нам и не надо" - рассуждения в стиле "зелен виноград".
VN> Ну я лично про "не надо" не кричал:) Его необходимость не
VN> настолько высокая как многим представляется - вот это факт.
VN> Конечно, удобнее было бы с ним.
Ну дык. Некоторые вообще без подсветки синтаксиса живут, и не понимают,
зачем она нужна.
VN> А если вводить какой-то code browser с его возможностями, то кроме
VN> автодополнения потребуется ещё много чего и, возможно, раньше чем
VN> автодополнение. Например, я часто использую старый юниксовый приём
VN> с префиксом поля в структуре зависящим от имени структурного типа:
VN> искать wc_flags или mco_flags в большом куске кода (а особенно в
VN> нескольких файлах) значительно проще, чем искать просто flags и
VN> отделять затем по контексту, к какому из 10-20-500 структурных
VN> типов этот flags относится (что в случае конструкций типа
VN> vx_op->> vxo_parse->vop_convert->mco_flags превращается в
VN> медленную китайскую пытку). Толковый code browser мог бы
VN> автоматизировать эту работу, выполнив операцию "grep по таким-то
VN> файлам всех строк где используется mail_convert_operation::flags".
VN> И мне лично это на порядок важнее автодополнения.
Что-то эти префиксы подозрительно напоминают венгерскую нотацию :)
Valentin Nechayev
>>> Vadim Goncharov wrote:
VG>>> Нет. Автодополнение никоим образом не привязано к венгерской нотации и
VG>>> [Visual] C/C++.
VN>> Я не говорил, что оно привязано. Я говорил, что это один из
VN>> наиболее мощных стимулов к использованию автодополнения, хоть и
VN>> косвенный. А где оно впервые появилось - тут уже без разницы.
VG> Я бы поспорил, что такой уж мощный. В венгерской нотации в коде обычно много
VG> переменных с одинаковым венгерским префиксом, а сами префиксы нередко
VG> весьма crunched так, что их по одной букве не автодополнить. В таких
VG> случаях венгерская нотация начинает снижать эффективность автодополнения :)
Ну если ты знаешь тип переменной то набрав какие-нибудь lpsz и затем
команду показать варианты - получаешь достаточное ускорение.
VG> Кстати, автодополнение автоматически исправляет регистр набранного, что
VG> в каком-нибудь Паскале просто повышает читабельность, а в Си жизненно
VG> необходимо :)
Это скорее в каком-нибудь Питоне жизненно необходимо;) В Си
компилятор всё заметит.
VN>> А если вводить какой-то code browser с его возможностями, то кроме
VN>> автодополнения потребуется ещё много чего и, возможно, раньше чем
VN>> автодополнение. Например, я часто использую старый юниксовый приём
VN>> с префиксом поля в структуре зависящим от имени структурного типа:
VN>> искать wc_flags или mco_flags в большом куске кода (а особенно в
VN>> нескольких файлах) значительно проще, чем искать просто flags и
VN>> отделять затем по контексту, к какому из 10-20-500 структурных
VN>> типов этот flags относится (что в случае конструкций типа
VN>> vx_op->> vxo_parse->vop_convert->mco_flags превращается в
VN>> медленную китайскую пытку). Толковый code browser мог бы
VN>> автоматизировать эту работу, выполнив операцию "grep по таким-то
VN>> файлам всех строк где используется mail_convert_operation::flags".
VN>> И мне лично это на порядок важнее автодополнения.
VG> Что-то эти префиксы подозрительно напоминают венгерскую нотацию :)
Даже если они внешне первично похожи - суть у них противоположная.
-netch-
Mikhail Gusarov
You (ne...@segfault.kiev.ua) wrote:
VN> Ну если ты знаешь тип переменной то набрав какие-нибудь lpsz и
VN> затем команду показать варианты - получаешь достаточное
VN> ускорение.
Это неинтересно. Я вот никогда типов не помню. А помню её смысл,
выраженный именем. А уж в чём оно - в виде shared_ptr, в виде
контейнера, lpsz (за такое, кстати, в C++ надо руки рубить, в
особенности за 'l') или чём ещё - это уже дело десятое.
--
Mikhail Gusarov
ICQ UIN: 111575219
JID: dott...@jabber.dottedmag.net
Alexey Feldgendler
Здорово, Valentin!
_Буду предельно краток. Это ответ на письмо_ Valentin Nechayev _к_ Victor
Wagner <Tuesday September 27 2005 10:31>
VN> 1) Сначала придумали венгерку как средство включить в имя объекта
VN> (в широком смысле) данные о его типе и использовании, рассчитывая
VN> при этом в значительной мере на средства периода компиляции: за
VN> соответствием декорации имени и режима использования следит
VN> программист, а за наличием таких имён в декларации - компилятор,
VN> уже на этапе компиляции, а не написания;
Ссылка по теме:
http://www.joelonsoftware.com/articles/Wrong.html
В этой статье объясняется, чем должна была быть венгеpская нотация, и чем она
стала на самом деле. Я был поpажён этим. С венгеpской нотацией вышел пp%$б
галактических масштабов, в pезyльтате котоpого из хоpошей, в общем-то, идеи
полyчилась такая pеализация, что от неё избавиться -- счастье.
До скорого!
Alexey.
... С начала месяца прошло 670 часов.
Alexey Feldgendler
Здорово, Andrey!
_Буду предельно краток. Это ответ на письмо_ Andrey Ladugin _к_ Andriy O.
Beregovenko <Tuesday September 27 2005 19:17>
AB>> Hе совсем так, это не ИДЕ, это удобная для разработки среда...
AB>> особенно не может не порадовать система помощи (man, info)
AL> можно ли как-то проводить поиск по всем man, info?
AL> что-то типа GUI - морды объединения их в единую MSDN :)
Много таких систем. См. напpимеp dwww, swish++.
До скорого!
Alexey.
... С начала месяца прошло 2413126 секунд.
Vadim Goncharov
On Wed, 28 Sep 2005 14:25:10 +0000 (UTC); Valentin Nechayev wrote about 'Re: провокация ;)':
VG>>>> Нет. Автодополнение никоим образом не привязано к венгерской нотации и
VG>>>> [Visual] C/C++.
VN>>> Я не говорил, что оно привязано. Я говорил, что это один из
VN>>> наиболее мощных стимулов к использованию автодополнения, хоть и
VN>>> косвенный. А где оно впервые появилось - тут уже без разницы.
VG>> Я бы поспорил, что такой уж мощный. В венгерской нотации в коде обычно много
VG>> переменных с одинаковым венгерским префиксом, а сами префиксы нередко
VG>> весьма crunched так, что их по одной букве не автодополнить. В таких
VG>> случаях венгерская нотация начинает снижать эффективность автодополнения :)
VN> Ну если ты знаешь тип переменной то набрав какие-нибудь lpsz и затем
VN> команду показать варианты - получаешь достаточное ускорение.
Эффективность уже снизилась - ведь я должен это _набрать_ - тогда как
автодополнение предназначено для освобождения меня от набора.
VG>> Кстати, автодополнение автоматически исправляет регистр набранного, что
VG>> в каком-нибудь Паскале просто повышает читабельность, а в Си жизненно
VG>> необходимо :)
VN> Это скорее в каком-нибудь Питоне жизненно необходимо;) В Си
VN> компилятор всё заметит.
Ага, а мне потом возвращаться и править только лишь регистр? Нафиг,
нафиг, когда сия фича все за меня сделает, причем поимеем читабельность
уже в процессе.
VN>>> А если вводить какой-то code browser с его возможностями, то кроме
VN>>> автодополнения потребуется ещё много чего и, возможно, раньше чем
VN>>> автодополнение. Например, я часто использую старый юниксовый приём
VN>>> с префиксом поля в структуре зависящим от имени структурного типа:
VN>>> искать wc_flags или mco_flags в большом куске кода (а особенно в
VN>>> нескольких файлах) значительно проще, чем искать просто flags и
VN>>> отделять затем по контексту, к какому из 10-20-500 структурных
VN>>> типов этот flags относится (что в случае конструкций типа
VN>>> vx_op-> vxo_parse->vop_convert->mco_flags превращается в
VN>>> медленную китайскую пытку). Толковый code browser мог бы
VN>>> автоматизировать эту работу, выполнив операцию "grep по таким-то
VN>>> файлам всех строк где используется mail_convert_operation::flags".
VN>>> И мне лично это на порядок важнее автодополнения.
VG>> Что-то эти префиксы подозрительно напоминают венгерскую нотацию :)
VN> Даже если они внешне первично похожи - суть у них противоположная.
Как ни странно, в основе та же - в имя переменной вводится некая
контекстная информация о ней, будь то тип или объект-контейнер.
Valentin Nechayev
>>> Vadim Goncharov wrote:
VN>> Ну если ты знаешь тип переменной то набрав какие-нибудь lpsz и затем
VN>> команду показать варианты - получаешь достаточное ускорение.
VG> Эффективность уже снизилась - ведь я должен это _набрать_ - тогда как
VG> автодополнение предназначено для освобождения меня от набора.
Тогда эффективность достигается только в том случае, когда компьютер
догадывается за тебя, что набирать, во всех случаях и без ошибок.
Иначе ты ведь как-то должен обозначить, что именно будешь
подставлять? И автодополнение будет эффективнее ручного набора
только в том случае, когда оно требует меньше действий, чем выбор из
представленного меню. Включая перевод руки с клавиатуры на мышу.
VG>>> Кстати, автодополнение автоматически исправляет регистр набранного, что
VG>>> в каком-нибудь Паскале просто повышает читабельность, а в Си жизненно
VG>>> необходимо :)
VN>> Это скорее в каком-нибудь Питоне жизненно необходимо;) В Си
VN>> компилятор всё заметит.
VG> Ага, а мне потом возвращаться и править только лишь регистр? Нафиг,
VG> нафиг, когда сия фича все за меня сделает, причем поимеем читабельность
VG> уже в процессе.
Но жизненной необходимостью это назвать совсем уж нельзя.
VG>>> Что-то эти префиксы подозрительно напоминают венгерскую нотацию :)
VN>> Даже если они внешне первично похожи - суть у них противоположная.
VG> Как ни странно, в основе та же - в имя переменной вводится некая
VG> контекстная информация о ней, будь то тип или объект-контейнер.
Угу.
-netch-
Ilya Anfimov
Alexey Feldgendler <Alexey.Fe...@p27.f111.n5000.z2.fidonet.org> пишет:
Замечательно. Прочитал с удовольствием. Редкий случай -- joel
откопал что-то интересное.
Интересно, много ли стандартов построены на подобных ошибках :-)?
Mikhail Gusarov
You (Alexey.Fe...@p27.f111.n5000.z2.fidonet.org) wrote:
AF> Ссылка по теме: http://www.joelonsoftware.com/articles/Wrong.html
AF> В этой статье объясняется, чем должна была быть венгеpская
AF> нотация, и чем она стала на самом деле.Я был поpажён этим. С
AF> венгеpской нотацией вышел пp%$б галактических масштабов, в
AF> pезyльтате котоpого из хоpошей, в общем-то, идеи полyчилась такая
AF> pеализация, что от неё избавиться -- счастье.
Идея ужасная. Руками разводить safe/unsafe-строки - идиотизм того
времени, когда этого не могли сделать компиляторы. Почему его request
не возвращает значение типа UnsafeString, которое превращается в
String в помощью escape()?
Lev Walkin
Mikhail Gusarov wrote:
"Joel, это наше всё".
Достоинство этой статьи не в том, что предлагает Joel взамен (и правда, "фи"),
а в том, что он "откопал" на популярный свет нечто, что восстанавливает
справедливость, веру в венгров и Санта Клауса. При этом то, что он является
своего рода инсайдером (после работы в MS), делает его слова довольно
выпуклыми.
--
Lev Walkin
v...@lionet.info
Mikhail Gusarov
You (v...@lionet.info) wrote:
>> http://www.joelonsoftware.com/articles/Wrong.html
LW> Достоинство этой статьи не в том, что предлагает Joel взамен (и
LW> правда, "фи"), а в том, что он "откопал" на популярный свет
LW> нечто, что восстанавливает справедливость, веру в венгров и Санта
LW> Клауса.
А недостатком - то, что он откопал это уже тогда, когда есть другие
механизмы, но всё ещё предлагает как панацею.
Ilya Anfimov
>
> You (Alexey.Fe...@p27.f111.n5000.z2.fidonet.org) wrote:
>
> AF> Ссылка по теме: http://www.joelonsoftware.com/articles/Wrong.html
>
> AF> В этой статье объясняется, чем должна была быть венгеpская
> AF> нотация, и чем она стала на самом деле.Я был поpажён этим. С
> AF> венгеpской нотацией вышел пp%$б галактических масштабов, в
> AF> pезyльтате котоpого из хоpошей, в общем-то, идеи полyчилась такая
> AF> pеализация, что от неё избавиться -- счастье.
>
> Идея ужасная. Руками разводить safe/unsafe-строки - идиотизм того
Это нормальная практика при программировании на ассемблере.
Dmitry Grebeniuk
MG> Идея ужасная. Руками разводить safe/unsafe-строки - идиотизм того
MG> времени, когда этого не могли сделать компиляторы. Почему его request
MG> не возвращает значение типа UnsafeString, которое превращается в
MG> String в помощью escape()?
Потому что по условиям задачи в программе у него должны храниться именно not
escaped строки, а при выводе преобразовываться в escaped. Садитесь, два.
Если придумывать решение в мире C++, то правильным должно быть создание
класса SafeString такого, чтобы только для него были определены операции вывода
строк пользователю. Соответственно, на эти операции следует навесить escape().
bye
Mikhail Gusarov
You (Dmitry.G...@f105.n469.z2.fidonet.org) wrote:
MG>> Идея ужасная. Руками разводить safe/unsafe-строки - идиотизм
MG>> того времени, когда этого не могли сделать компиляторы. Почему
MG>> его request не возвращает значение типа UnsafeString, которое
MG>> превращается в String в помощью escape()?
DG> Потому что по условиям задачи в программе у него должны храниться
DG> именно not escaped строки, а при выводе преобразовываться в
DG> escaped. Садитесь, два.
Осторожнее, осторожнее. Не на форуме детском, однако.
DG> Если придумывать решение в мире C++, то правильным должно быть
DG> создание класса SafeString такого, чтобы только для него были
DG> определены операции вывода строк пользователю. Соответственно,
DG> на эти операции следует навесить escape().
1. Те же яйца, только сбоку - использование системы типов для того,
для чего предлагается венгерская нотация. В чем будут существенные
возражения против того, что я сказал?
2. И при чём тут C++? Его система типов не сильно располагает.
Valentin Nechayev
>>> Mikhail Gusarov wrote:
AF>> Ссылка по теме: http://www.joelonsoftware.com/articles/Wrong.html
AF>> В этой статье объясняется, чем должна была быть венгеpская
AF>> нотация, и чем она стала на самом деле.Я был поpажён этим. С
AF>> венгеpской нотацией вышел пp%$б галактических масштабов, в
AF>> pезyльтате котоpого из хоpошей, в общем-то, идеи полyчилась такая
AF>> pеализация, что от неё избавиться -- счастье.
MG> Идея ужасная. Руками разводить safe/unsafe-строки - идиотизм того
MG> времени, когда этого не могли сделать компиляторы. Почему его request
MG> не возвращает значение типа UnsafeString, которое превращается в
MG> String в помощью escape()?
Не годится. Ты в SQL отдавать будешь тоже строки с &, < и тому
подобными словечками?
На самом деле идея с типизацией конечно правильная, но вот
реализация должна была бы быть где-то такой: для вывода в html
используется потомок ostream, у которого обычный оператор вывода
("<<") производит конверсию недопустимых символов, а специальный
(назовём его putcode) выводит без конверсии.
Хотя и против этого найдётся лом с резьбой:
out.putcode("<p>" + userdata + "</p>")
и фиг потом найдёшь подобные диверсии в коде. Так что следующей
итерацией будет создание типа HtmlCodeString...
-netch-
Vadim Goncharov
On Wed, 28 Sep 2005 18:47:31 +0000 (UTC); Valentin Nechayev wrote about 'Re: провокация ;)':
VN>>> Ну если ты знаешь тип переменной то набрав какие-нибудь lpsz и затем
VN>>> команду показать варианты - получаешь достаточное ускорение.
VG>> Эффективность уже снизилась - ведь я должен это _набрать_ - тогда как
VG>> автодополнение предназначено для освобождения меня от набора.
VN> Тогда эффективность достигается только в том случае, когда компьютер
VN> догадывается за тебя, что набирать, во всех случаях и без ошибок.
VN> Иначе ты ведь как-то должен обозначить, что именно будешь
Не. Эффективность - это когда я с фичей затрачу на набор кода (значительного
куска кода, чтоб можно было статистически оценивать) меньше времени, чем
без нее, причем сокращение будет заметным на фоне общего времени.
...А когда он догадываться сможет, набирать уже не надо будет -
нейроинтерфейсы и все такое :)
VN> подставлять? И автодополнение будет эффективнее ручного набора
VN> только в том случае, когда оно требует меньше действий, чем выбор из
VN> представленного меню. Включая перевод руки с клавиатуры на мышу.
Никаких мышей, у нас есть курсорные стрелки. Смотреть же в случае всего
кода (опять статистика) следует не на уменьшение количества нажатых клавиш,
а на суммарное время. В одних случаях, время сокращается значительно, в
других выбор может потребовать много нажатий. Но и в этом случае -
вдруг автоповтор "стрелки вниз" окажется быстрее ручного набора? :)
VG>>>> Кстати, автодополнение автоматически исправляет регистр набранного, что
VG>>>> в каком-нибудь Паскале просто повышает читабельность, а в Си жизненно
VG>>>> необходимо :)
VN>>> Это скорее в каком-нибудь Питоне жизненно необходимо;) В Си
VN>>> компилятор всё заметит.
VG>> Ага, а мне потом возвращаться и править только лишь регистр? Нафиг,
VG>> нафиг, когда сия фича все за меня сделает, причем поимеем читабельность
VG>> уже в процессе.
VN> Но жизненной необходимостью это назвать совсем уж нельзя.
Ну да, это лишь вопрос правильной реализации фичи.
Vadim Goncharov
On Thu, 29 Sep 2005 07:20:09 +0000 (UTC); Mikhail Gusarov wrote about 'Re: провокация ;)':
LW>> Достоинство этой статьи не в том, что предлагает Joel взамен (и
LW>> правда, "фи"), а в том, что он "откопал" на популярный свет
LW>> нечто, что восстанавливает справедливость, веру в венгров и Санта
LW>> Клауса.
MG> А недостатком - то, что он откопал это уже тогда, когда есть другие
MG> механизмы, но всё ещё предлагает как панацею.
Например?
Vadim Goncharov
On Thu, 29 Sep 2005 06:39:59 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
VN>> 1) Сначала придумали венгерку как средство включить в имя объекта
VN>> (в широком смысле) данные о его типе и использовании, рассчитывая
VN>> при этом в значительной мере на средства периода компиляции: за
VN>> соответствием декорации имени и режима использования следит
VN>> программист, а за наличием таких имён в декларации - компилятор,
VN>> уже на этапе компиляции, а не написания;
>> Ссылка по теме:
>> http://www.joelonsoftware.com/articles/Wrong.html
>> В этой статье объясняется, чем должна была быть венгеpская нотация, и чем она
>> стала на самом деле. Я был поpажён этим. С венгеpской нотацией вышел пp%$б
>> галактических масштабов, в pезyльтате котоpого из хоpошей, в общем-то, идеи
>> полyчилась такая pеализация, что от неё избавиться -- счастье.
IA> Замечательно. Прочитал с удовольствием. Редкий случай -- joel
IA> откопал что-то интересное.
А что, joel разве в основном фигню пишет?
IA> Интересно, много ли стандартов построены на подобных ошибках :-)?
Навскидку - границы портов TCP 5000 и 50000.
Mikhail Gusarov
You (vadimn...@tpu.ru) wrote:
LW>>> Достоинство этой статьи не в том, что предлагает Joel взамен (и
LW>>> правда, "фи"), а в том, что он "откопал" на популярный свет
LW>>> нечто, что восстанавливает справедливость, веру в венгров и
LW>>> Санта Клауса.
MG>> А недостатком - то, что он откопал это уже тогда, когда есть
MG>> другие механизмы, но всё ещё предлагает как панацею.
VG> Например?
Отмотка треда - 50$/тред.
Mikhail Gusarov
You (ne...@segfault.kiev.ua) wrote:
VN> Не годится. Ты в SQL отдавать будешь тоже строки с &, < и
VN> тому подобными словечками?
Нет, естественно. Я лишь показал, что идея с префиксами давно
разруливается типизацией. Не будем придираться к конкретным примерам,
ок?
Dmitry Grebeniuk
VN> ("<<") производит конверсию недопустимых символов, а специальный
VN> (назовём его putcode) выводит без конверсии.
VN> Хотя и против этого найдётся лом с резьбой:
VN> out.putcode("<p>" + userdata + "</p>")
VN> и фиг потом найдёшь подобные диверсии в коде. Так что следующей
VN> итерацией будет создание типа HtmlCodeString...
Hе знаю, насколько Ваш HtmlCodeString близок к моим идеям, но я бы решал
задачу приблизительно такой системой типов (вполне реально положить на объекты,
если язык не поддерживает подобные типы):
type html_tree = list html_element
and html_element =
[ Tag of html_tag and list html_attribute and list html_element
| Text of string
]
and html_attribute = string * string;
Этим решается и проблема правильной генерации html, и правильной расстановки
тэгов и аттрибутов, и довольно-таки удобно бегать по такому дереву по нужде,
если вдруг появится.
bye
Dmytro Rud
> Hе знаю, насколько Ваш HtmlCodeString близок к моим идеям, но я бы
> решал задачу приблизительно такой системой типов (вполне реально
> положить на объекты, если язык не поддерживает подобные типы):
>
> type html_tree = list html_element
> and html_element =
> [ Tag of html_tag and list html_attribute and list html_element
> | Text of string
> ]
> and html_attribute = string * string;
>
> Этим решается и проблема правильной генерации html, и правильной
> расстановки тэгов и аттрибутов, и довольно-таки удобно бегать по
> такому дереву по нужде, если вдруг появится.
Заново изобретаешь DOM? ;-)
--
rnd.
Ilya Anfimov
> Hi Ilya Anfimov!
>
> On Thu, 29 Sep 2005 06:39:59 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
>
> VN>> 1) Сначала придумали венгерку как средство включить в имя объекта
> VN>> (в широком смысле) данные о его типе и использовании, рассчитывая
> VN>> при этом в значительной мере на средства периода компиляции: за
> VN>> соответствием декорации имени и режима использования следит
> VN>> программист, а за наличием таких имён в декларации - компилятор,
> VN>> уже на этапе компиляции, а не написания;
> >> Ссылка по теме:
> >> http://www.joelonsoftware.com/articles/Wrong.html
> >> В этой статье объясняется, чем должна была быть венгеpская нотация, и чем она
> >> стала на самом деле. Я был поpажён этим. С венгеpской нотацией вышел пp%$б
> >> галактических масштабов, в pезyльтате котоpого из хоpошей, в общем-то, идеи
> >> полyчилась такая pеализация, что от неё избавиться -- счастье.
> IA> Замечательно. Прочитал с удовольствием. Редкий случай -- joel
> IA> откопал что-то интересное.
>
> А что, joel разве в основном фигню пишет?
Я не могу сказать -- фигню. Он пишет какие-то свои эмоции,
которые мне обычно не очень интересны. У самого таких вагон.
У него при этом имеются попытки рационализировать свои эмоции.
Обычно, если они (эти эмоции, выводы из них) не очевидны, то
доводы достаточно слабые и потому не интересные. Если они
очевидны, то эти попытки тем более не интересны.
>
> IA> Интересно, много ли стандартов построены на подобных ошибках :-)?
>
> Навскидку - границы портов TCP 5000 и 50000.
Не знаю эту историю. А что там, с портом 5000?
>
Vadim Goncharov
On Thu, 29 Sep 2005 13:40:05 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
IA>> Замечательно. Прочитал с удовольствием. Редкий случай -- joel
IA>> откопал что-то интересное.
>> А что, joel разве в основном фигню пишет?
IA> Я не могу сказать -- фигню. Он пишет какие-то свои эмоции,
IA> которые мне обычно не очень интересны. У самого таких вагон.
IA> У него при этом имеются попытки рационализировать свои эмоции.
IA> Обычно, если они (эти эмоции, выводы из них) не очевидны, то
IA> доводы достаточно слабые и потому не интересные. Если они
IA> очевидны, то эти попытки тем более не интересны.
Имхо, он пишет несколько для другой аудитории, потому тебе и не
интересно :)
IA>> Интересно, много ли стандартов построены на подобных ошибках :-)?
>> Навскидку - границы портов TCP 5000 и 50000.
IA> Не знаю эту историю. А что там, с портом 5000?
Для исходящих соединений случайный порт по стандарту должен лежать в
диапазоне от 1024 до 5000. Естественно, через сколько-то лет загруженным
серверам этого диапазона перестало хватать. И только в конце 90-х
выяснилось, что это была опечатка - вместо 5000 должно было быть 50000.
Но до сих пор во многих системах стоит дефолт в 5000.
Vadim Goncharov
On Thu, 29 Sep 2005 12:30:05 +0000 (UTC); Mikhail Gusarov wrote about 'Re: провокация ;)':
LW>>>> Достоинство этой статьи не в том, что предлагает Joel взамен (и
LW>>>> правда, "фи"), а в том, что он "откопал" на популярный свет
LW>>>> нечто, что восстанавливает справедливость, веру в венгров и
LW>>>> Санта Клауса.
MG>>> А недостатком - то, что он откопал это уже тогда, когда есть
MG>>> другие механизмы, но всё ещё предлагает как панацею.
VG>> Например?
MG> Отмотка треда - 50$/тред.
Отмотал тред вплоть до ссылки на Джоэля. Замены тому, что он предлагает,
ты не привел.
Ilya Anfimov
>
> On Thu, 29 Sep 2005 13:40:05 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
>
> IA>> Замечательно. Прочитал с удовольствием. Редкий случай -- joel
> IA>> откопал что-то интересное.
> >> А что, joel разве в основном фигню пишет?
> IA> Я не могу сказать -- фигню. Он пишет какие-то свои эмоции,
> IA> которые мне обычно не очень интересны. У самого таких вагон.
> IA> У него при этом имеются попытки рационализировать свои эмоции.
> IA> Обычно, если они (эти эмоции, выводы из них) не очевидны, то
> IA> доводы достаточно слабые и потому не интересные. Если они
> IA> очевидны, то эти попытки тем более не интересны.
>
> Имхо, он пишет несколько для другой аудитории, потому тебе и не
> интересно :)
Сомневаюсь. Про аудиторию. Эмоции очень часто схожи.
Ilya Anfimov
>
> On Thu, 29 Sep 2005 12:30:05 +0000 (UTC); Mikhail Gusarov wrote about 'Re: провокация ;)':
>
> LW>>>> Достоинство этой статьи не в том, что предлагает Joel взамен (и
> LW>>>> правда, "фи"), а в том, что он "откопал" на популярный свет
> LW>>>> нечто, что восстанавливает справедливость, веру в венгров и
> LW>>>> Санта Клауса.
> MG>>> А недостатком - то, что он откопал это уже тогда, когда есть
> MG>>> другие механизмы, но всё ещё предлагает как панацею.
> VG>> Например?
> MG> Отмотка треда - 50$/тред.
>
> Отмотал тред вплоть до ссылки на Джоэля. Замены тому, что он предлагает,
> ты не привел.
Таки строгая типизация. И разделение типов -- того, что получено
от пользователя и того, что прошло проверки и является
безопасным.
Mikhail Gusarov
You (uni...@web.de) wrote:
DR> Заново изобретаешь DOM? ;-)
Кстати, да: при работе с DOM подобных проблем не возникает. Остается
лишь распространить эту идею на случай неявного дерева, типа
output_page :: HTTPResponse HTMLPage -> HTTPResponse
add_attribute :: HTMLPage EscapedString EscapedString -> HTMLPage
add_text :: HTMLPage EscapedString -> HTMLPage
...
Для обратного есть SAX, а вот для генерации я что-то стандартных
средств не припомню.
Vadim Goncharov
On Thu, 29 Sep 2005 14:37:21 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
LW>>>>> Достоинство этой статьи не в том, что предлагает Joel взамен (и
LW>>>>> правда, "фи"), а в том, что он "откопал" на популярный свет
LW>>>>> нечто, что восстанавливает справедливость, веру в венгров и
LW>>>>> Санта Клауса.
MG>>>> А недостатком - то, что он откопал это уже тогда, когда есть
MG>>>> другие механизмы, но всё ещё предлагает как панацею.
VG>>> Например?
MG>> Отмотка треда - 50$/тред.
>> Отмотал тред вплоть до ссылки на Джоэля. Замены тому, что он предлагает,
>> ты не привел.
IA> Таки строгая типизация. И разделение типов -- того, что получено
IA> от пользователя и того, что прошло проверки и является
IA> безопасным.
OK. Но Джоэль в статье вообще-то говорил несколь о другом. А именно, о
том, как сразу _видеть_ по коду возможные ошибки. Строгая типизация тут
не решает проблему, ждем, пока поругается компилятор.
Строгая типизация рулит, да. Но речь-то была о другом аспекте.
Vadim Goncharov
On Thu, 29 Sep 2005 14:35:49 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
IA>>> Замечательно. Прочитал с удовольствием. Редкий случай -- joel
IA>>> откопал что-то интересное.
>>> А что, joel разве в основном фигню пишет?
IA>> Я не могу сказать -- фигню. Он пишет какие-то свои эмоции,
IA>> которые мне обычно не очень интересны. У самого таких вагон.
IA>> У него при этом имеются попытки рационализировать свои эмоции.
IA>> Обычно, если они (эти эмоции, выводы из них) не очевидны, то
IA>> доводы достаточно слабые и потому не интересные. Если они
IA>> очевидны, то эти попытки тем более не интересны.
>> Имхо, он пишет несколько для другой аудитории, потому тебе и не
>> интересно :)
IA> Сомневаюсь. Про аудиторию. Эмоции очень часто схожи.
Как сказать-то... Он полезен тем, что потенциально доносит информацию раньше.
Учиться лучше на чужих ошибках, а не на своих. Вот пример: он в статье
пишет объявление переменной:
char* one, two;
И дальше объясняет, почему это неправильно. Я, привыкший к строгой
типизации, и никогда не понимавший, зачем в Сях так запутанно пишут
объявления переменных, на эту багу напоролся не так давно (буквально
так и объявил - обе указатели, логично вынести в определение типа).
Вот читал после этого Джоэля, испытывал те же эмоции, и думал, что если
бы раньше прочитал про эту очередную убогость С, было бы лучше...
Victor Wagner
DR>Заново изобретаешь DOM? ;-)
Думаю, что после того как ты назвал эту страшную аббревиатуру, не будет
он его заново изобретать. Возьмет любую готовую реализацию.
--
Mikhail Gusarov
You (vadimn...@tpu.ru) wrote:
IA>> Таки строгая типизация. И разделение типов -- того, что
IA>> получено от пользователя и того, что прошло проверки и является
IA>> безопасным.
VG> OK. Но Джоэль в статье вообще-то говорил несколь о другом. А
VG> именно, о том, как сразу _видеть_ по коду возможные
VG> ошибки. Строгая типизация тут не решает проблему, ждем, пока
VG> поругается компилятор.
Эти вещи в IDE также могут быть сделаны (и даже сделаны, в той же
IntelliJ IDEA, или Eclipse SDK) видимыми, причем речь уже идет не о
"случайно увидеть пару багов", а о "вот вам полный список
несовместимых присваиваний".
Vadim Goncharov
On Thu, 29 Sep 2005 15:30:14 +0000 (UTC); Mikhail Gusarov wrote about 'Re: провокация ;)':
VG>> OK. Но Джоэль в статье вообще-то говорил несколь о другом. А
VG>> именно, о том, как сразу _видеть_ по коду возможные
VG>> ошибки. Строгая типизация тут не решает проблему, ждем, пока
VG>> поругается компилятор.
MG> Эти вещи в IDE также могут быть сделаны (и даже сделаны, в той же
MG> IntelliJ IDEA, или Eclipse SDK) видимыми, причем речь уже идет не о
MG> "случайно увидеть пару багов", а о "вот вам полный список
MG> несовместимых присваиваний".
Неплохо. Но пока это не получило широкго распространения (а с С/С++ и не
получит), подход Джоэля работает лучше.
Ilya Anfimov
>
> On Thu, 29 Sep 2005 14:37:21 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
>
> LW>>>>> Достоинство этой статьи не в том, что предлагает Joel взамен (и
> LW>>>>> правда, "фи"), а в том, что он "откопал" на популярный свет
> LW>>>>> нечто, что восстанавливает справедливость, веру в венгров и
> LW>>>>> Санта Клауса.
> MG>>>> А недостатком - то, что он откопал это уже тогда, когда есть
> MG>>>> другие механизмы, но всё ещё предлагает как панацею.
> VG>>> Например?
> MG>> Отмотка треда - 50$/тред.
> >> Отмотал тред вплоть до ссылки на Джоэля. Замены тому, что он предлагает,
> >> ты не привел.
> IA> Таки строгая типизация. И разделение типов -- того, что получено
> IA> от пользователя и того, что прошло проверки и является
> IA> безопасным.
>
> OK. Но Джоэль в статье вообще-то говорил несколь о другом. А именно, о
> том, как сразу _видеть_ по коду возможные ошибки. Строгая типизация тут
> не решает проблему, ждем, пока поругается компилятор.
1) А вам мало?
2) А некоторым несознательным личностям текстовый редактор
синтаксические ошибки подсвечивает. Ещё немного -- и он это всем
начнёт делать.
Ilya Anfimov
>
> On Thu, 29 Sep 2005 15:30:14 +0000 (UTC); Mikhail Gusarov wrote about 'Re: провокация ;)':
>
> VG>> OK. Но Джоэль в статье вообще-то говорил несколь о другом. А
> VG>> именно, о том, как сразу _видеть_ по коду возможные
> VG>> ошибки. Строгая типизация тут не решает проблему, ждем, пока
> VG>> поругается компилятор.
> MG> Эти вещи в IDE также могут быть сделаны (и даже сделаны, в той же
> MG> IntelliJ IDEA, или Eclipse SDK) видимыми, причем речь уже идет не о
> MG> "случайно увидеть пару багов", а о "вот вам полный список
> MG> несовместимых присваиваний".
>
> Неплохо. Но пока это не получило широкго распространения (а с С/С++ и не
> получит), подход Джоэля работает лучше.
Потому тут уже и говорилось -- это нужно для ассемблера. За прошедшие
15 лет появились другие средства решать подобные проблемы.
>
Ilya Anfimov
Ну, во-первых это хорошая, годная статься Джоэла :-).
А во-вторых в сях есть на что понапарываться, и пока по этому не
попрыгаешь -- никакой Джоэл не поможет.
Vadim Goncharov
On Thu, 29 Sep 2005 15:53:49 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
IA>> Таки строгая типизация. И разделение типов -- того, что получено
IA>> от пользователя и того, что прошло проверки и является
IA>> безопасным.
>> OK. Но Джоэль в статье вообще-то говорил несколь о другом. А именно, о
>> том, как сразу _видеть_ по коду возможные ошибки. Строгая типизация тут
>> не решает проблему, ждем, пока поругается компилятор.
IA> 1) А вам мало?
Ага. Я хочу сразу, чтоб ускорение было. Как в соседнем треде про
автодополнение :)
IA> 2) А некоторым несознательным личностям текстовый редактор
IA> синтаксические ошибки подсвечивает. Ещё немного -- и он это всем
IA> начнёт делать.
Пока все на такой редактор не перейдут... :)
Vadim Goncharov
On Thu, 29 Sep 2005 15:55:51 +0000 (UTC); Ilya Anfimov wrote about 'Re: провокация ;)':
>> char* one, two;
>> И дальше объясняет, почему это неправильно. Я, привыкший к строгой
>> типизации, и никогда не понимавший, зачем в Сях так запутанно пишут
>> объявления переменных, на эту багу напоролся не так давно (буквально
>> так и объявил - обе указатели, логично вынести в определение типа).
>> Вот читал после этого Джоэля, испытывал те же эмоции, и думал, что если
>> бы раньше прочитал про эту очередную убогость С, было бы лучше...
IA> Ну, во-первых это хорошая, годная статься Джоэла :-).
Ж%)
IA> А во-вторых в сях есть на что понапарываться, и пока по этому не
IA> попрыгаешь -- никакой Джоэл не поможет.
Чего-то можно избежать сразу, если знать. Он в другой статье "Back to
basics" пишет, что столько пробелм возникает из-за того, что сутденты не
знают, как оно там унутрях работает. А потом как напарываются на те же
сишные строки, и все равно приходиться разбираться, но тратить гораздо
больше времени.
Mikhail Gusarov
You (vadimn...@tpu.ru) wrote:
VG> Ага. Я хочу сразу, чтоб ускорение было. Как в соседнем треде про
VG> автодополнение :)
А ускорение будет. Не в наборе текста, так в общей скорости
разработки: тестирование на пару циклов такая типизация вполне может
сократить, отловив сразу дурацкие ошибки.
2RK: агитируй наше начальство за OCaml, аргументируя за ускорение
тестирвания =)
Victor Wagner
>> Я, привыкший к строгой типизации, и никогда не понимавший,
>> зачем в Сях так запутанно пишут объявления переменных, на
>> эту багу напоролся не так давно (буквально так и объявил -
>> обе указатели, логично вынести в определение типа). Вот
>> читал после этого Джоэля, испытывал те же эмоции, и думал,
>> что если бы раньше прочитал про эту очередную убогость С,
>> было бы лучше...
IA> во-вторых в сях есть на что понапарываться, и пока по
IA> этому не попрыгаешь -- никакой Джоэл не поможет.
Не Джоэла надо читать, а Питера ван дер Линдена - "Expert C
Programming". У ван дер Линдена и квалификация повыше чем у Джоэла, и
опыт работы побольше, да к тому же преимущественно эхотажный, в отличие
от Джоэла.
--
Сверхчеловек должен быть сверхчеловечен.
Max Khon
29 Sep 05 18:53, you wrote to Vadim Goncharov:
IA> 1) А вам мало?
IA> 2) А некоторым несознательным личностям текстовый редактор
IA> синтаксические ошибки подсвечивает. Ещё немного -- и он это всем
IA> начнёт делать.
а что в этом плохого? я скажем без syntax highlighting (скажем, в vim) уже
плохо ориентируюсь
/fjoe
Ruslan Kosolapov
VG>> Ага. Я хочу сразу, чтоб ускорение было. Как в соседнем треде про
VG>> автодополнение :)
MG> А ускорение будет. Не в наборе текста, так в общей скорости
MG> разработки: тестирование на пару циклов такая типизация вполне
MG> может сократить, отловив сразу дурацкие ошибки.
MG> 2RK: агитируй наше начальство за OCaml, аргументируя за ускорение
MG> тестирвания =)
Эх, жалко эха публичная...
Хотя... Может через год-два что и получится...
Только вот я не за OCaml. Я за erlang :)
--
=[ Sokrat: Я что-то сделал, сейчас попробую понять что...
Ruslan Kosolapov
IA>> А во-вторых в сях есть на что понапарываться, и пока по этому не
IA>> попрыгаешь -- никакой Джоэл не поможет.
VG> Чего-то можно избежать сразу, если знать. Он в другой статье
VG> "Back to basics" пишет, что столько пробелм возникает из-за того,
VG> что сутденты не знают, как оно там унутрях работает. А потом как
VG> напарываются на те же сишные строки, и все равно приходиться
VG> разбираться, но тратить гораздо больше времени.
Не знаешь си - не пиши на нём.
Это на tcl можно писать, не зная tcl. А на си так нельзя.
PS: Джоеля читать после книг специалистов иногда просто смешно. Но
неплохие статьи у него есть.
--
=[ Внедрить - внедрили, а вывнедрить - забыли.
Artem Chuprina
VG>> Чего-то можно избежать сразу, если знать. Он в другой статье
VG>> "Back to basics" пишет, что столько пробелм возникает из-за того,
VG>> что сутденты не знают, как оно там унутрях работает. А потом как
VG>> напарываются на те же сишные строки, и все равно приходиться
VG>> разбираться, но тратить гораздо больше времени.
RK> Не знаешь си - не пиши на нём.
RK> Это на tcl можно писать, не зная tcl. А на си так нельзя.
На tcl тоже нельзя. Подстановки будут происходить не в тот момент.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Правки Белявского, сделанные им в рабочей копии головы
Из коммитлога.
Dmitry Grebeniuk
DR>> Заново изобретаешь DOM? ;-)
VW> Думаю, что после того как ты назвал эту страшную аббревиатуру, не
VW> будет он его заново изобретать. Возьмет любую готовую реализацию.
Hе факт, что 1) под мой язык оно есть, 2) мне нужно тянуть всё это дело, 3)
меня устроит императивный стиль программирования, который насаждает DOM, 4) мне
нужно хранить всё дерево в памяти.
bye
Ilya Anfimov
>==[ Mikhail -> Vadim:
>
> VG>> Ага. Я хочу сразу, чтоб ускорение было. Как в соседнем треде про
> VG>> автодополнение :)
> MG> А ускорение будет. Не в наборе текста, так в общей скорости
> MG> разработки: тестирование на пару циклов такая типизация вполне
> MG> может сократить, отловив сразу дурацкие ошибки.
> MG> 2RK: агитируй наше начальство за OCaml, аргументируя за ускорение
> MG> тестирвания =)
>
> Эх, жалко эха публичная...
>
> Хотя... Может через год-два что и получится...
>
> Только вот я не за OCaml. Я за erlang :)
А нетипизированный erlang тебе тут не поможет.
>
Mikhail Gusarov
You (Dmitry.G...@f105.n469.z2.fidonet.org) wrote:
DG> Hе факт, что 1) под мой язык оно есть, 2) мне нужно тянуть всё
DG> это дело, 3) меня устроит императивный стиль программирования,
DG> который насаждает DOM, 4) мне нужно хранить всё дерево в памяти.
DOM не насаждает никакого стиля программирования. А всё дерево у тебя
и так хранится, судя из вышепоскипанного определения типа.
Victor Wagner
wrote:
DG> hi, Victor
VW>> Думаю, что после того как ты назвал эту страшную
VW>> любую готовую реализацию.
DG> Hе факт, что 1) под мой язык оно есть, 2) мне нужно тянуть
Если ты не сам его придумал, этот язык, и у него есть хоть какая-никакая
пользовательская база - скорее всего есть.
DG> всё это дело, 3) меня устроит императивный стиль
DG> программирования, который насаждает DOM, 4) мне нужно
Какой такой императивный стиль? Одна из первых реализаций DOM-образной
обрабоки SGML (DSSSL) была на Scheme. Думаешь зря такой малоимперативный
язык был выбран.
--
-- Хочу стать богом!
-- Замечательно! Бери рацию, и дуй на другой конец полигона. У нас
посредников не хватает
- с одной ролевой игры
Ruslan Kosolapov
VG>>> Чего-то можно избежать сразу, если знать. Он в другой статье
VG>>> "Back to basics" пишет, что столько пробелм возникает из-за
VG>>> того, что сутденты не знают, как оно там унутрях работает. А
VG>>> потом как напарываются на те же сишные строки, и все равно
VG>>> приходиться разбираться, но тратить гораздо больше времени.
RK>> Не знаешь си - не пиши на нём.
RK>> Это на tcl можно писать, не зная tcl. А на си так нельзя.
AC> На tcl тоже нельзя. Подстановки будут происходить не в тот
AC> момент.
Эээ... А можно пример, когда это приводит к серьёзным проблемам?
--
=[ защитникам удаётся в углу центрального круга отобрать мяч у Шевченко
=[ -- футбол на ОРТ
john gladkih
> IA>> А во-вторых в сях есть на что понапарываться, и пока по этому не
> IA>> попрыгаешь -- никакой Джоэл не поможет.
> VG> Чего-то можно избежать сразу, если знать. Он в другой статье
> VG> "Back to basics" пишет, что столько пробелм возникает из-за того,
> VG> что сутденты не знают, как оно там унутрях работает. А потом как
> VG> напарываются на те же сишные строки, и все равно приходиться
> VG> разбираться, но тратить гораздо больше времени.
>
> Не знаешь си - не пиши на нём.
> Это на tcl можно писать, не зная tcl. А на си так нельзя.
>
на нем вообще писать нельзя. даже зная. поскольку написать на pure
TCL нечего. сам по себе он бесмысленен.
--
john, http://john.kak-sam.to
john gladkih
> VG>> Ага. Я хочу сразу, чтоб ускорение было. Как в соседнем треде про
> VG>> автодополнение :)
> MG> А ускорение будет. Не в наборе текста, так в общей скорости
> MG> разработки: тестирование на пару циклов такая типизация вполне
> MG> может сократить, отловив сразу дурацкие ошибки.
> MG> 2RK: агитируй наше начальство за OCaml, аргументируя за ускорение
> MG> тестирвания =)
>
> Эх, жалко эха публичная...
>
> Хотя... Может через год-два что и получится...
>
> Только вот я не за OCaml. Я за erlang :)
для редактора текстов с абсолютно бесмысленной фитчей типа
аффтакамплитта? :)
--
john, http://john.kak-sam.to
Artem Chuprina
VG>>>> Чего-то можно избежать сразу, если знать. Он в другой статье
VG>>>> "Back to basics" пишет, что столько пробелм возникает из-за
VG>>>> того, что сутденты не знают, как оно там унутрях работает. А
VG>>>> потом как напарываются на те же сишные строки, и все равно
VG>>>> приходиться разбираться, но тратить гораздо больше времени.
RK>>> Не знаешь си - не пиши на нём.
RK>>> Это на tcl можно писать, не зная tcl. А на си так нельзя.
AC>> На tcl тоже нельзя. Подстановки будут происходить не в тот
AC>> момент.
RK> Эээ... А можно пример, когда это приводит к серьёзным проблемам?
Если я правильно ошибаюсь, в Уэлше их хватает. Я сейчас приведу пример
из другой области. Только что. Ага, с tcl. Добавка в .tkabber/config
в proc postload строчек
set ::osd::options {--pos=bottom --lines=8 --color=ForestGreen}
set ::osd::osdfont [option get . osdfont Osdfont]
работала на ноутбуке, но не работает на рабочей машине. Предлагается
_без_ знания tcl угадать, почему и сделать, чтоб работало. Подсказка:
до мысли "на рабочей не стоит osd plugin" догадаться несложно. И не
должен стоять. Дальше? Собственно, со знанием tcl эту ошибку можно
просто не допустить.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Делу время, потехе - деньги.
Кнышев
Kirill Frolov
On Tue, 27 Sep 05 20:17:05 +0400, Andrey Ladugin wrote:
AL> можно ли как-то проводить поиск по всем man, info?
AL> что-то типа GUI - морды объединения их в единую MSDN :)
google://
Kirill Frolov
On Tue, 27 Sep 05 15:43:30 +0400, Max Khon wrote:
MK> вообще говоря, автодополнение по своей сути является неким разумным
MK> дополнением
MK> к той функциональности, которую предоставляет ctags. а венгерская нотация
MK> тут
MK> совсем непричем.
Я не способен донести в голове вычитанное в MSDN имя функции из окна
MSDN в окно редактора. У меня объёма памяти на эти
lpsz-чего-то-там-ещё-на-пол-страницы-В-рАзнЫх-РегИСтрАх-ВпеРемЕШку
попросту не хватает. Запомнить тем более невозможно. Потому и
все эти подсказки и дополнения. Корень проблемы в этом. В отсутствии
запоминающихся коротких имён.
Max Khon
28 Sep 05 02:30, you wrote to me:
MK>> вообще говоря, автодополнение по своей сути является неким
MK>> разумным
KF> дополнением
MK>> к той функциональности, которую предоставляет ctags. а венгерская
MK>> нотация тут совсем непричем.
KF> Я не способен донести в голове вычитанное в MSDN имя функции из окна
KF> MSDN в окно редактора. У меня объёма памяти на эти
KF> lpsz-чего-то-там-ещё-на-пол-страницы-В-рАзнЫх-РегИСтрАх-ВпеРемЕШку
KF> попросту не хватает. Запомнить тем более невозможно. Потому и
KF> все эти подсказки и дополнения. Корень проблемы в этом. В отсутствии
KF> запоминающихся коротких имён.
все правильно, только MSDN и микрософтовские API тут непричем.
эппловские нативные API видел? да что там apple.. в любом современном
тулките/библиотеке так дела обстоят. возьми тот же openssl или libxml2.
/fjoe
Vadim Goncharov
On Fri, 30 Sep 2005 05:09:14 +0000 (UTC); Ruslan Kosolapov wrote about 'Re: провокация ;)':
IA>>> А во-вторых в сях есть на что понапарываться, и пока по этому не
IA>>> попрыгаешь -- никакой Джоэл не поможет.
VG>> Чего-то можно избежать сразу, если знать. Он в другой статье
VG>> "Back to basics" пишет, что столько пробелм возникает из-за того,
VG>> что сутденты не знают, как оно там унутрях работает. А потом как
VG>> напарываются на те же сишные строки, и все равно приходиться
VG>> разбираться, но тратить гораздо больше времени.
RK> Не знаешь си - не пиши на нём.
RK> Это на tcl можно писать, не зная tcl. А на си так нельзя.
RK> PS: Джоеля читать после книг специалистов иногда просто смешно. Но
RK> неплохие статьи у него есть.
В этой статье Джоэль писал главным образом не о Си.
Valentin Nechayev
>>> Vadim Goncharov wrote:
VG>>> Чего-то можно избежать сразу, если знать. Он в другой статье
VG>>> "Back to basics" пишет, что столько пробелм возникает из-за того,
VG>>> что сутденты не знают, как оно там унутрях работает. А потом как
VG>>> напарываются на те же сишные строки, и все равно приходиться
VG>>> разбираться, но тратить гораздо больше времени.
RK>> Не знаешь си - не пиши на нём.
RK>> Это на tcl можно писать, не зная tcl. А на си так нельзя.
RK>> PS: Джоеля читать после книг специалистов иногда просто смешно. Но
RK>> неплохие статьи у него есть.
VG> В этой статье Джоэль писал главным образом не о Си.
В "Back to basics"? Мне так не показалось. Кстати, читая её
следует помнить, что реализации malloc'а, которые в ней описаны,
вымерли лет 5-10 назад.
-netch-
Valentin Nechayev
>>> Vadim Goncharov wrote:
IA>>> Интересно, много ли стандартов построены на подобных ошибках :-)?
>>> Навскидку - границы портов TCP 5000 и 50000.
IA>> Не знаю эту историю. А что там, с портом 5000?
VG> Для исходящих соединений случайный порт по стандарту должен лежать в
VG> диапазоне от 1024 до 5000. Естественно, через сколько-то лет загруженным
VG> серверам этого диапазона перестало хватать. И только в конце 90-х
VG> выяснилось, что это была опечатка - вместо 5000 должно было быть 50000.
VG> Но до сих пор во многих системах стоит дефолт в 5000.
Заметим, что для тяжелонагруженным серверам вообще 16-битного пространства
портов мало.
А методы стандартизации в IETF у меня в последнее время вызывают только
ужас. Исправления ошибок в RFC нет в принципе. Иногда их исправляют
в апдейтах, но часто и этого не бывает. В ключевом RFC - 791 (TCP) сидит
ошибка (urgent pointer), которую прокомментировали в 1122, чем и
ограничились. Чтобы построить адекватную реализацию, надо обладать
эзотерическими способностями, или же вариться в системе лет 10 чтобы знать
все тонкости и грабли. И как это называть?
-netch-
Vadim Goncharov
On Sat, 1 Oct 2005 06:36:42 +0000 (UTC); Valentin Nechayev wrote about 'Re: провокация ;)':
VG>>>> Чего-то можно избежать сразу, если знать. Он в другой статье
VG>>>> "Back to basics" пишет, что столько пробелм возникает из-за того,
VG>>>> что сутденты не знают, как оно там унутрях работает. А потом как
VG>>>> напарываются на те же сишные строки, и все равно приходиться
VG>>>> разбираться, но тратить гораздо больше времени.
RK>>> Не знаешь си - не пиши на нём.
RK>>> Это на tcl можно писать, не зная tcl. А на си так нельзя.
RK>>> PS: Джоеля читать после книг специалистов иногда просто смешно. Но
RK>>> неплохие статьи у него есть.
VG>> В этой статье Джоэль писал главным образом не о Си.
VN> В "Back to basics"? Мне так не показалось. Кстати, читая её
VN> следует помнить, что реализации malloc'а, которые в ней описаны,
VN> вымерли лет 5-10 назад.
Он философствует об образовании, используя особености Си как иллюстративный
материал. Более значимы там рассуждения о введении Java в качестве
начального изучения программирования, и быстродейтсвии XML :)
Vadim Goncharov
On Sat, 1 Oct 2005 08:13:15 +0000 (UTC); Valentin Nechayev wrote about 'Порты (Re: провокация ;))':
IA>>>> Интересно, много ли стандартов построены на подобных ошибках :-)?
>>>> Навскидку - границы портов TCP 5000 и 50000.
IA>>> Не знаю эту историю. А что там, с портом 5000?
VG>> Для исходящих соединений случайный порт по стандарту должен лежать в
VG>> диапазоне от 1024 до 5000. Естественно, через сколько-то лет загруженным
VG>> серверам этого диапазона перестало хватать. И только в конце 90-х
VG>> выяснилось, что это была опечатка - вместо 5000 должно было быть 50000.
VG>> Но до сих пор во многих системах стоит дефолт в 5000.
VN> Заметим, что для тяжелонагруженным серверам вообще 16-битного пространства
VN> портов мало.
Угу.
VN> А методы стандартизации в IETF у меня в последнее время вызывают только
VN> ужас. Исправления ошибок в RFC нет в принципе. Иногда их исправляют
VN> в апдейтах, но часто и этого не бывает. В ключевом RFC - 791 (TCP) сидит
VN> ошибка (urgent pointer), которую прокомментировали в 1122, чем и
VN> ограничились. Чтобы построить адекватную реализацию, надо обладать
VN> эзотерическими способностями, или же вариться в системе лет 10 чтобы знать
VN> все тонкости и грабли. И как это называть?
Да, я в курсе, что OOB в TCP не следует использовать ни при каких
обстоятельствах. И вообще, Ceterum censeo IPv6 esse delendam :)
Valentin Nechayev
>>> Vadim Goncharov wrote:
VN>> А методы стандартизации в IETF у меня в последнее время вызывают только
VN>> ужас. Исправления ошибок в RFC нет в принципе. Иногда их исправляют
VN>> в апдейтах, но часто и этого не бывает. В ключевом RFC - 791 (TCP) сидит
VN>> ошибка (urgent pointer), которую прокомментировали в 1122, чем и
VN>> ограничились. Чтобы построить адекватную реализацию, надо обладать
VN>> эзотерическими способностями, или же вариться в системе лет 10 чтобы знать
VN>> все тонкости и грабли. И как это называть?
VG> Да, я в курсе, что OOB в TCP не следует использовать ни при каких
VG> обстоятельствах. И вообще, Ceterum censeo IPv6 esse delendam :)
Я вообще-то серьезно, а ты стебешься :(
Пример с TCP просто самый показательный. Но таких примеров вагон.
-netch-
Alexander Kotelnikov
VN>
IA> Интересно, много ли стандартов построены на подобных ошибках :-)?
>>>> Навскидку - границы портов TCP 5000 и 50000.
IA> Не знаю эту историю. А что там, с портом 5000?
VG> Для исходящих соединений случайный порт по стандарту должен лежать в
VG> диапазоне от 1024 до 5000. Естественно, через сколько-то лет загруженным
VG> серверам этого диапазона перестало хватать. И только в конце 90-х
VG> выяснилось, что это была опечатка - вместо 5000 должно было быть 50000.
VG> Но до сих пор во многих системах стоит дефолт в 5000.
VN> Заметим, что для тяжелонагруженным серверам вообще 16-битного пространства
VN> портов мало.
VN>
VN> А методы стандартизации в IETF у меня в последнее время вызывают только
VN> ужас. Исправления ошибок в RFC нет в принципе. Иногда их исправляют
VN> в апдейтах, но часто и этого не бывает. В ключевом RFC - 791 (TCP)
VN> сидит
793
VN> ошибка (urgent pointer), которую прокомментировали в 1122, чем и
VN> ограничились. Чтобы построить адекватную реализацию, надо обладать
VN> эзотерическими способностями, или же вариться в системе лет 10 чтобы знать
VN> все тонкости и грабли. И как это называть?
Гм. Conforming realisation сделать совсем не сложно, вот только пользы
от URG больше не станет. Или это уже пошло обобщение на все заковырки?
Тогда с одной стороны в 1122 сделать больше и не могли, а с другой
десять лет вариться не обязятально, можно собрать все бумажки по TCP
(ну да, будет папочка раз в двадцать больше чем оригинальный rfc) и
работать.
--
Alexander Kotelnikov
Saint-Petersburg, Russia
Alex Semenyaka
01 Oct 05 12:13, you wrote to Vadim Goncharov:
VN> А методы стандартизации в IETF у меня в последнее время вызывают только
VN> ужас.
Что мешает исправлять ситуацию?
VN> Исправления ошибок в RFC нет в принципе.
А что - были? Это противоречит идеи RFC, насколько я понимаю. Hашли ошибку -
выпустили новый RFC.
VN> Иногда их исправляют в апдейтах, но часто и этого не бывает. В
VN> ключевом RFC - 791 (TCP) сидит ошибка (urgent pointer), которую
VN> прокомментировали в 1122, чем и ограничились. Чтобы построить
VN> адекватную реализацию, надо обладать эзотерическими способностями,
VN> или же вариться в системе лет 10 чтобы знать все тонкости и грабли.
VN> И как это называть?
При том, что никто не мешает тебе зарегистрироваться на ietf.org и продвигать
свои идеи - наверное, ленью? ;)
Hа региональном райповском митинге (на который из Киева приехал, по-моему,
ровно 1 человек) Алекс Зинин специально уговаривал всех не сидеть на попе, а
участвовать...
Alex
Valentin Nechayev
>>> Alex Semenyaka wrote:
VN>> А методы стандартизации в IETF у меня в последнее время вызывают только
VN>> ужас.
AS> Что мешает исправлять ситуацию?
VN>> Исправления ошибок в RFC нет в принципе.
AS> А что - были? Это противоречит идеи RFC, насколько я понимаю. Hашли ошибку -
AS> выпустили новый RFC.
Во-первых, RFC как таковые - не специфика IETF. Например, основной
документ классической реализации PAM называется OSF-RFC 86.0. Даже
не заглядывая в гугл, можно понять, что это уже никак не
одномерная схема IETF.
Во-вторых, где эти новые выпущенные RFC? Если даже в одном из
центральных RFC явные ошибки - что мешало даже через 5 лет
выпустить обновление? Но прошло уже 24 года. Я приведу
нетехнический аргумент, но я бы на месте руководителя этой системы
уже умер от позора, видя, что в ключевом RFC явная ошибка и это не
исправлено за 24 года.
Это тебе и ответ на "что мешает исправить?" - теми средствами что
доступны мне - это не исправляется в принципе. Если люди наверху
не понимают всего кошмара такой ситуации - или их это устраивает,
или это я один такой ненормальный и хочу слишком странного. В
любом из этих двух случаев надо быть "особой приближенной к
императору", чтобы поменять установившуюся за почти 30 лет
систему.
VN>> прокомментировали в 1122, чем и ограничились. Чтобы построить
VN>> адекватную реализацию, надо обладать эзотерическими способностями,
VN>> или же вариться в системе лет 10 чтобы знать все тонкости и грабли.
VN>> И как это называть?
AS> При том, что никто не мешает тебе зарегистрироваться на ietf.org и продвигать
AS> свои идеи - наверное, ленью? ;)
AS> Hа региональном райповском митинге (на который из Киева приехал, по-моему,
AS> ровно 1 человек) Алекс Зинин специально уговаривал всех не сидеть на попе, а
AS> участвовать...
Участвовать в чём? В своём локальном углу кодификации и
стандартизации я участвую. Дальше что?
Ничего личного, но как в последнее время стало модно спрашивать "а
ты что сделал?" даже не пытаясь разобраться в обстановке...
-netch-
Alex Semenyaka
02 Oct 05 12:27, you wrote to me:
VN>>> А методы стандартизации в IETF у меня в последнее время вызывают
VN>>> только ужас.
AS>> Что мешает исправлять ситуацию?
VN>>> Исправления ошибок в RFC нет в принципе.
AS>> А что - были? Это противоречит идеи RFC, насколько я понимаю. Hашли
AS>> ошибку - выпустили новый RFC.
VN> Во-первых, RFC как таковые - не специфика IETF.
А тут я про IETF и не писал ничего пока. Я писал про то, что не бывает
исправлений RFC. Hи в последнее время, ни в начальное время - никогда ;)
VN> Во-вторых, где эти новые выпущенные RFC? Если даже в одном из
VN> центральных RFC явные ошибки - что мешало даже через 5 лет
VN> выпустить обновление?
А тут уже отвечал - видимо, лень тех, кому это не нравится? :)
VN> Hо прошло уже 24 года. Я приведу нетехнический аргумент, но я бы на
VN> месте руководителя этой системы уже умер от позора, видя, что в
VN> ключевом RFC явная ошибка и это не исправлено за 24 года.
Hу вот не надо только шашками махать. Ты прекрасно знаешь, что, несмотря на
1122, прекрасно сосуществуют обе реализации URG. Так что не всё так просто.
Есть и попроще вещи, которые реализуются не по стандарту :) Может, сначала с
них начать, решить - как правильно, как написано или как делается? :)
VN> Это тебе и ответ на "что мешает исправить?" - теми средствами что
VN> доступны мне - это не исправляется в принципе.
Откуда такой странный вывод?
VN> или это я один такой ненормальный и хочу слишком странного. В
VN> любом из этих двух случаев надо быть "особой приближенной к
VN> императору",
Ты пробовал и не получилось? ;) Или откуда дровишки?
Опять же, мне как-то больше верится Зинину. Он рассказывал, как стал
руководителем группы по маршрутизации и коммутации. Hичего сверхъестественного,
и никуда быть приближённым не надо было.
VN>>> прокомментировали в 1122, чем и ограничились. Чтобы построить
VN>>> адекватную реализацию, надо обладать эзотерическими способностями,
VN>>> или же вариться в системе лет 10 чтобы знать все тонкости и
VN>>> грабли. И как это называть?
AS>> При том, что никто не мешает тебе зарегистрироваться на ietf.org и
AS>> продвигать свои идеи - наверное, ленью? ;) Hа региональном
AS>> райповском митинге (на который из Киева приехал, по-моему, ровно 1
AS>> человек) Алекс Зинин специально уговаривал всех не сидеть на попе, а
AS>> участвовать...
VN> Участвовать в чём? В своём локальном углу кодификации и
VN> стандартизации я участвую. Дальше что?
В работе рабочих групп IETF. Подготавливаешь RFC и вносишь на рассмотрение
соответствующей WG. Делал?
VN> Hичего личного, но как в последнее время стало модно спрашивать "а
VN> ты что сделал?" даже не пытаясь разобраться в обстановке...
Я как бы читал большую часть RFC по TCP, и, опять же, слушал представителя IETF
- не верить ему оснований нет. Поэтому повода для обсуждения, как же всё
ужасно, я не вижу. Вопрос "что конкретно именно ты сделал?", как несложно
заметить из контекста, вполне уместный.
Я вот больше не люблю рассуждений на тему "как всё плохо, а дальше будет только
хуже". По логике, тут вообще нечего дискутировать, а сразу можно предлагать в
ответ "убить себя об стену" (tm). Hо я, заметь, этого не предлагаю.
Alex
Valentin Nechayev
>>> Alex Semenyaka wrote:
AS>>> А что - были? Это противоречит идеи RFC, насколько я понимаю. Hашли
AS>>> ошибку - выпустили новый RFC.
VN>> Во-первых, RFC как таковые - не специфика IETF.
AS> А тут я про IETF и не писал ничего пока. Я писал про то, что не бывает
AS> исправлений RFC. Hи в последнее время, ни в начальное время - никогда ;)
И вот это и есть принципиальная неправильность. Или они должны
исправляться, или стандарты должны быть не RFC, а стандартами.
AS> В работе рабочих групп IETF. Подготавливаешь RFC и вносишь на рассмотрение
AS> соответствующей WG. Делал?
Ты опять говоришь совсем о другом. Не должно быть нового RFC,
должна быть правка старого.
AS> Я вот больше не люблю рассуждений на тему "как всё плохо, а дальше будет только
AS> хуже". По логике, тут вообще нечего дискутировать, а сразу можно предлагать в
AS> ответ "убить себя об стену" (tm). Hо я, заметь, этого не предлагаю.
Убиваться об стену предлагай тем, кто не работает. Я - работаю в
текущих условиях. Но и не считаю осмысленными затраты времени, сил
и ресурсов на непроизводительные траты из-за чужого
организационного бардака.
-netch-
Valentin Nechayev
>>> Alexander Kotelnikov wrote:
AK> Гм. Conforming realisation сделать совсем не сложно, вот только пользы
AK> от URG больше не станет. Или это уже пошло обобщение на все заковырки?
Да. Например, из свежих. RFC3261 (SIP). 8.2.6.2 говорит "must be
equal". 20.20 говорит "two From: fields are equivalent..." И мы
спорим, является ли equivalent в 20.20 equal в 8.2.6.2. Смешно? В
рассылке (sipчего-то@ietf.org) ищем реплику: "да, сравнивать по
20.20. в следующей версии стандарта это будет оговорено." RFC3261
- 2002. Обсуждение - 2003. На дворе - 2005. И вместо того чтобы
ругаться с производителями железных клиентов, не лучше ли было бы
выпустить обновление?
Смотрим на тех кто работает более нормальным образом - например,
ANSI. Заходим на www.t13.org. Errare humanum est? Замечательно, к
стандартам выходят technical corrigendums - не через 24 года и
даже не через 3, а максимум через месяц-два после обнаружения
проблемы. Да, за стандарт просят 15$ - ну просто фантастическая
сумма. Зато final draft (идентичный стандарту) бесплатен, разве
что радости не приносит;)))
AK> Тогда с одной стороны в 1122 сделать больше и не могли, а с другой
AK> десять лет вариться не обязятально, можно собрать все бумажки по TCP
AK> (ну да, будет папочка раз в двадцать больше чем оригинальный rfc) и
AK> работать.
И как "Requirements for Internet hosts" относится к TCP? Это
совершенно неочевидно;)
-netch-
Alex Nazarov
* 01 Oct 05 22:10, Valentin Nechayev wrote to Vadim Goncharov:
VG>> Да, я в курсе, что OOB в TCP не следует использовать ни при каких
VG>> обстоятельствах. И вообще, Ceterum censeo IPv6 esse delendam :)
VN> Я вообще-то серьезно, а ты стебешься :(
VN> Пример с TCP просто самый показательный. Hо таких примеров вагон.
А есть ли ресурс, собравший подобные недочеты?
Alex
Alexander Kotelnikov
AK> Гм. Conforming realisation сделать совсем не сложно, вот только пользы
AK> от URG больше не станет. Или это уже пошло обобщение на все заковырки?
VN> Да. Например, из свежих. RFC3261 (SIP). 8.2.6.2 говорит "must be
VN> equal". 20.20 говорит "two From: fields are equivalent..." И мы
VN> спорим, является ли equivalent в 20.20 equal в 8.2.6.2. Смешно? В
VN> рассылке (sipчего-то@ietf.org) ищем реплику: "да, сравнивать по
VN> 20.20. в следующей версии стандарта это будет оговорено." RFC3261
VN> - 2002. Обсуждение - 2003. На дворе - 2005. И вместо того чтобы
VN> ругаться с производителями железных клиентов, не лучше ли было бы
VN> выпустить обновление?
Забавно.
VN> Смотрим на тех кто работает более нормальным образом - например,
VN> ANSI. Заходим на www.t13.org. Errare humanum est? Замечательно, к
VN> стандартам выходят technical corrigendums - не через 24 года и
VN> даже не через 3, а максимум через месяц-два после обнаружения
VN> проблемы. Да, за стандарт просят 15$ - ну просто фантастическая
VN> сумма.
Когда 15, когда 150, а когда и 150 за том, а томов может быть
порядочно, что, впрочем, не означает, что стандарт безусловно должен
быть открытым.
VN> Зато final draft (идентичный стандарту) бесплатен, разве
VN> что радости не приносит;)))
Опс. Так хороши эти ANSI и ISO или нет?
AK> Тогда с одной стороны в 1122 сделать больше и не могли, а с другой
AK> десять лет вариться не обязятально, можно собрать все бумажки по TCP
AK> (ну да, будет папочка раз в двадцать больше чем оригинальный rfc) и
AK> работать.
VN>
VN> И как "Requirements for Internet hosts" относится к TCP? Это
VN> совершенно неочевидно;)
Ну... действительно, совершенно непонятно, почему 1122 не UPDATES
793. Обновляет, еще как.
Valentin Nechayev
>>> Alexander Kotelnikov wrote:
AK> Когда 15, когда 150, а когда и 150 за том, а томов может быть
AK> порядочно, что, впрочем, не означает, что стандарт безусловно должен
AK> быть открытым.
IETF открыт по определению:) но это не значит что надо вместо стандартов
делать RFC.
VN>> Зато final draft (идентичный стандарту) бесплатен, разве
VN>> что радости не приносит;)))
AK> Опс. Так хороши эти ANSI и ISO или нет?
Я имел в виду, что по нему можно сделать реализацию, но нельзя говорить,
что она соответствует стандарту.
VN>> И как "Requirements for Internet hosts" относится к TCP? Это
VN>> совершенно неочевидно;)
AK> Ну... действительно, совершенно непонятно, почему 1122 не UPDATES
AK> 793. Обновляет, еще как.
И это тоже - он в updates не упомянут:(
-netch-
Kirill Frolov
On Thu, 29 Sep 05 14:51:02 +0400, Vadim Goncharov wrote:
VG> Hе. Эффективность - это когда я с фичей затрачу на набор кода
VG> (значительного
VG> куска кода, чтоб можно было статистически оценивать) меньше времени, чем
VG> без нее, причем сокращение будет заметным на фоне общего времени.
VG> ...А когда он догадываться сможет, набирать уже не надо будет -
VG> нейроинтерфейсы и все такое :)
А правда что вин-программисты как и профессиональные машинистки
по 2000 знаков в минуту выдают?
VG> других выбор может потребовать много нажатий. Hо и в этом случае -
VG> вдруг автоповтор "стрелки вниз" окажется быстрее ручного набора? :)
Ручной набор с дополнением (как в виндовс ехплорере сделано) быстрей
по числу нажатий на клавиши -- это очевидно должно быть (букв 26, а
стрелки только 2).
Vadim Goncharov
On Sat, 1 Oct 2005 18:10:44 +0000 (UTC); Valentin Nechayev wrote about 'Re: Порты':
VN>>> А методы стандартизации в IETF у меня в последнее время вызывают только
VN>>> ужас. Исправления ошибок в RFC нет в принципе. Иногда их исправляют
VN>>> в апдейтах, но часто и этого не бывает. В ключевом RFC - 791 (TCP) сидит
VN>>> ошибка (urgent pointer), которую прокомментировали в 1122, чем и
VN>>> ограничились. Чтобы построить адекватную реализацию, надо обладать
VN>>> эзотерическими способностями, или же вариться в системе лет 10 чтобы знать
VN>>> все тонкости и грабли. И как это называть?
VG>> Да, я в курсе, что OOB в TCP не следует использовать ни при каких
VG>> обстоятельствах. И вообще, Ceterum censeo IPv6 esse delendam :)
VN> Я вообще-то серьезно, а ты стебешься :(
VN> Пример с TCP просто самый показательный. Но таких примеров вагон.
Я абсолютно серьезен. OOB вообще вреден иделогически (даже
безотносительно непростительных багов конкретно в TCP) - выбивается из
парадигмы непрерывного потока байт. Твой же разгром IPv6 я где-то читал,
и ППКС.
Vadim Goncharov
On Sun, 02 Oct 2005 04:19:11 +0400; Kirill Frolov wrote about 'Re: провокация ;)':
VG>> Hе. Эффективность - это когда я с фичей затрачу на набор кода
VG>> (значительного
VG>> куска кода, чтоб можно было статистически оценивать) меньше времени, чем
VG>> без нее, причем сокращение будет заметным на фоне общего времени.
VG>> ...А когда он догадываться сможет, набирать уже не надо будет -
VG>> нейроинтерфейсы и все такое :)
KF> А правда что вин-программисты как и профессиональные машинистки
KF> по 2000 знаков в минуту выдают?
Это вам Рабинович по телефону напел?
VG>> других выбор может потребовать много нажатий. Hо и в этом случае -
VG>> вдруг автоповтор "стрелки вниз" окажется быстрее ручного набора? :)
KF> Ручной набор с дополнением (как в виндовс ехплорере сделано) быстрей
KF> по числу нажатий на клавиши -- это очевидно должно быть (букв 26, а
KF> стрелки только 2).
Если переменные начинаются с одинаковых префиксов, то нет.
Alex Semenyaka
02 Oct 05 14:36, you wrote to me:
AS>>>> А что - были? Это противоречит идеи RFC, насколько я понимаю.
AS>>>> Hашли ошибку - выпустили новый RFC.
VN>>> Во-первых, RFC как таковые - не специфика IETF.
AS>> А тут я про IETF и не писал ничего пока. Я писал про то, что не
AS>> бывает исправлений RFC. Hи в последнее время, ни в начальное время -
AS>> никогда ;)
VN> И вот это и есть принципиальная неправильность. Или они должны
VN> исправляться, или стандарты должны быть не RFC, а стандартами.
Hе вижу ничего такого уж фатального в том, что процесс организован так, а не
иначе. Изменение номена RFC (а так и происходит, когда RFC исправляют) - что в
этом ужасного? А уж вопрос названий ("стандарт", "RFC" или ещё как) - так и
вовсе кажется смешным.
AS>> В работе рабочих групп IETF. Подготавливаешь RFC и вносишь на
AS>> рассмотрение соответствующей WG. Делал?
VN> Ты опять говоришь совсем о другом. Hе должно быть нового RFC,
VN> должна быть правка старого.
Почему?
VN> Hо и не считаю осмысленными затраты времени, сил и ресурсов на
VN> непроизводительные траты из-за чужого организационного бардака.
В чём бардак-то? Раньше вроде как был в тексте RFC, теперь вроде как в
процедуре. Hадо бы определиться :)
Alex
Valentin Nechayev
>>> Alex Semenyaka wrote:
VN>> И вот это и есть принципиальная неправильность. Или они должны
VN>> исправляться, или стандарты должны быть не RFC, а стандартами.
AS> Hе вижу ничего такого уж фатального в том, что процесс организован так, а не
AS> иначе. Изменение номена RFC (а так и происходит, когда RFC исправляют) - что в
AS> этом ужасного? А уж вопрос названий ("стандарт", "RFC" или ещё как) - так и
AS> вовсе кажется смешным.
Разница в том, что
1) психологически правка существующего - событие меньшее, чем выпуск
нового. Поэтому против выпуска нового RFC с нефундаментальными
правками возражений всегда больше, чем против обновлённой версии
стандарта.
2) в источниках, как своих, так и чужих, закрепляются номера. Если
сказано "RFC793" и при этом присутствуют RFC793-1981 (начальный) и
RFC793-1987 (обновлённый) - всё равно ссылка будет на 793,
конкретная версия будет упоминаться только в случаях типа "XXX
соответствует версии 1981, хотя выпущен в 2000; почему не версии
1987?" Связи же между разными номерами типа "obsoleted by" требуют
явной проверки на устарелость.
VN>> Hо и не считаю осмысленными затраты времени, сил и ресурсов на
VN>> непроизводительные траты из-за чужого организационного бардака.
AS> В чём бардак-то? Раньше вроде как был в тексте RFC, теперь вроде как в
AS> процедуре. Hадо бы определиться :)
Я определился, только ты никак не хочешь прочесть. Бардак в процедуре,
а в RFC - ошибки. Которые или лечатся правильной процедурой, или
поддерживаются и усиливаются в бардаке. В случае RFC имеем второе.
-netch-
Valentin Nechayev
>>> Vadim Goncharov wrote:
VN>> Я вообще-то серьезно, а ты стебешься :(
VN>> Пример с TCP просто самый показательный. Но таких примеров вагон.
VG> Я абсолютно серьезен. OOB вообще вреден иделогически (даже
VG> безотносительно непростительных багов конкретно в TCP) - выбивается из
VG> парадигмы непрерывного потока байт.
Да, эта дискуссия ещё свежа в памяти. И если помнишь, я выступал за
существование отдельного OOB канала. Который, как оказалось, вообще
не соответствует идеям заложенным в TCP. К сожалению.
VG> Твой же разгром IPv6 я где-то читал,
VG> и ППКС.
Эту аббревиатуру я не понял.
-netch-
Serg Oskin
> Ruslan Kosolapov <r...@plesk.ru> writes:
>
>
>> IA>> А во-вторых в сях есть на что понапарываться, и пока по этому не
>> IA>> попрыгаешь -- никакой Джоэл не поможет.
>> VG> "Back to basics" пишет, что столько пробелм возникает из-за того,
>> VG> что сутденты не знают, как оно там унутрях работает. А потом как
>> VG> напарываются на те же сишные строки, и все равно приходиться
>> VG> разбираться, но тратить гораздо больше времени.
>>
>>
>
>
> TCL нечего. сам по себе он бесмысленен.
С perl перепутал?.. :)
--
Serg. (http://oskin.ru)
~
~
:q!
Artem Chuprina
>>> IA>> А во-вторых в сях есть на что понапарываться, и пока по этому не
>>> IA>> попрыгаешь -- никакой Джоэл не поможет.
>>> VG> Чего-то можно избежать сразу, если знать. Он в другой статье
>>> VG> "Back to basics" пишет, что столько пробелм возникает из-за того,
>>> VG> что сутденты не знают, как оно там унутрях работает. А потом как
>>> VG> напарываются на те же сишные строки, и все равно приходиться
>>> VG> разбираться, но тратить гораздо больше времени.
>>>
>>> Не знаешь си - не пиши на нём.
>>> Это на tcl можно писать, не зная tcl. А на си так нельзя.
>>>
>> на нем вообще писать нельзя. даже зная. поскольку написать на pure
>> TCL нечего. сам по себе он бесмысленен.
SO> С perl перепутал?.. :)
С basic.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Секретный ключ, известный более чем одной персоне, называется публичным.
john gladkih
>>> IA>> А во-вторых в сях есть на что понапарываться, и пока по этому не
>>> IA>> попрыгаешь -- никакой Джоэл не поможет.
>>> VG> Чего-то можно избежать сразу, если знать. Он в другой статье
>>> VG> "Back to basics" пишет, что столько пробелм возникает из-за того,
>>> VG> что сутденты не знают, как оно там унутрях работает. А потом как
>>> VG> напарываются на те же сишные строки, и все равно приходиться
>>> VG> разбираться, но тратить гораздо больше времени.
>>>
>>> Не знаешь си - не пиши на нём.
>>> Это на tcl можно писать, не зная tcl. А на си так нельзя.
>>>
>> на нем вообще писать нельзя. даже зная. поскольку написать на pure
>> TCL нечего. сам по себе он бесмысленен.
>
> С perl перепутал?.. :)
>
нет. на pure perl можно писать то для чего он изначально
предназначен. ничем не лучше чем на awk, но чуть короче. а
тикль? что он? где он? в жопе, но это было изначально ясно.
--
john, http://john.kak-sam.to
Ruslan Kosolapov
>>>> Не знаешь си - не пиши на нём. Это на tcl можно писать, не зная
>>>> tcl. А на си так нельзя.
>>> на нем вообще писать нельзя. даже зная. поскольку написать на pure
>>> TCL нечего. сам по себе он бесмысленен.
>> С perl перепутал?.. :)
jg> нет. на pure perl можно писать то для чего он изначально
jg> предназначен. ничем не лучше чем на awk, но чуть короче. а тикль?
jg> что он? где он? в жопе, но это было изначально ясно.
Что-то я не понял, почему на perl можно писать то, для чего он
изначально предназначен, а на тикле нельзя?
--
=[ только сядешь поработать обязательно кто-нибудь разбудит...
=[ -- Sokrat, 2003