date:20090319

On 18 March 2009 17:08:20 Покотиленко Костик wrote:
 В Срд, 18/03/2009 в 16:31 +0300, Artem Chuprina пишет:
  Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
15:03:57 +0200:
 Ну так как, пробовать будем?

 Неа.

 Если посмотреть выше, то речь шла о демонах, а не парсерах
 текстовых файлов. Или Вы считаете их равнозначными задачами?

 Есть у меня и демоны на тикле, например, собирают и обрабатывают
 данные с цисок и других АТС. Написать то же самое на С большая
 работа (на тикле используются события для прослушивания множества
 сокетов, а на С придется создавать отдельные потоки), потому и не
 предлагаю как тестовую задачу (притом демоны умеют держать в
 in-memory SQLite database те данные, которые не удалось записать в
 persistent database), не говоря уж о реализации самой логики
 обработки.

 Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в
 которых соответствующие примитивы.
   
Вообще говоря, есть libevent, с помощью которой на Си событийно
писать проще. Но вообще прикладуху на Си писать не интересно, борьба
с языком(слишком низкоуровневый) и развивается паранойя при
использовании каждого указателя.
 
   ПК Прикол в том, что уровень языка Си выбирается программистом
  посредством ПК выбора библиотек нужных уровней. На libc конечно тяжело
  прикладуху ПК писать. Выбор за тобой, а не за языком, используй glib,
  gtk+, или что ПК тебе больше подходит для конкретной задачи.
 
   ПК Как я уже писал, на Си легко работать с объектной моделью, не
  сложнее ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
  ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
  ПК высокого уровня ограничивают тебя высотой своего уровня.
 
  Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
  получаешь высокоуровневый подъязык с неудобным синтаксисом и
  ... правильно, все равно заботой о распределении памяти (почистить за
  тобой все равно никто не сможет).

 В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
 потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
 потомков одной командой. Так что это дело инструментов, а GTK+ и кстати
 glib это умеют.

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

 Чем вдруг?

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

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

на асме тоже

Re: Perl or Python?

On 18 March 2009 20:11:58 Artem Chuprina wrote:
chaos - debian-russian@lists.debian.org @ Wed, 18 Mar 2009 17:00:46 +0200:
KM А новичку не все ли равно? Хоть BASIC. Дело-то не в
конкретном ЯП, KM а в общем уровне програмистской культуры. А
это только опыт и KM фундаментальные знания.

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

От языка почти не зависит. По-русски разговаривают и Сява и Сева.

Очень сильно зависит. Язык - это определяющий фактор. В
программирование - тем более.

Ага, ага. Написать два экрана if-ов вам не помешает ни один из ЯП.
Может и среди человеческих языков есть неудачные? Чего ж так много
быдла-то кругом?

Это теоретически не помешает. А практически я что-то ни в одном
функциональном языке (Common Lisp, Scheme, Ocaml, ELisp) такого не
встречал _ни разу_. А на пхп и васике -- сплошь и рядом; да и на
питоне попадалось. Я, признаться, и сам жалею, что моими первыми
языками были васик, си и паскаль а не тот же лисп, скажем. Возможно, и
сейчас бы иначе к программированию относился.

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

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

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

Functional programming is like describing your problem to a
mathematician. Imperative programming is like giving instructions to
an idiot.

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

Она есть. Преподавателей, которые могут ее назвать, нету.

Сейчас да, сейчас уже что угодно есть. Сейчас и инет есть.

Re: Perl or Python?

On 18 March 2009 17:40:46 Alexander Danilov wrote:
chaos пишет:
On 18 March 2009 16:44:06 Тихон Тарнавский wrote:
On Wed, 18.03.2009 17:09:18 , Konstantin Matyukhin wrote:
2009/3/18 Alexander Danilov alexander.a.dani...@gmail.com:
Konstantin Matyukhin пишет:
2009/3/18 Mikhail Gusarov dotted...@dottedmag.net:
Twas brillig at 16:30:26 18.03.2009 UTC+03 when kmatyuk...@gmail.com
did gyre and gimble:

KM А новичку не все ли равно? Хоть BASIC. Дело-то не в конкретном
ЯП, KM а в общем уровне програмистской культуры. А это только опыт
и KM фундаментальные знания.

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

От языка почти не зависит. По-русски разговаривают и Сява и Сева.

Очень сильно зависит. Язык - это определяющий фактор. В
программирование - тем более.

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

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

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

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

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

Re: nfs

On 19 March 2009 06:05:57 Andrei Lomov wrote:
 chaos wrote:
  On 15 March 2009 19:07:26 Andrei Lomov wrote:
  lenny
 
  Монтирую сетевые диски по nfs,
  если сервер, на котором диски физически расположены,
  выключается до того, как я их отмонтирую,
  KDE на моей машине приходит в полный ступор,
  лечится перезагрузкой даже не X, а всего.
  Приложения не из KDE продолжают работать.
 
  В чем может быть дело?
 
  Вот строчка из fstab клиента:
  small:/mnt/pool2/mnt/po...@small
  nfs user,retry=1,bg,noauto,rsize=8192,wsize=8192 0
 
  лучил не кеды, но лечил вырубанием fam

 Спасибо,
 можно чуть подробней про fam?
 File Alteration Monitor?
 В каком виде он живет в системе,
 как перезапустить, выключить?

aptitude remove fam :) 
а живёт он в /etc/init.d/fam :)

Re: Perl or Python?

2009-03-19 Пенетрантность Oleksandr Gavenko

On 18 March 2009 20:44:24 Тихон Тарнавский wrote:
On Wed, 18.03.2009 17:00:46 , chaos wrote:
On 18 March 2009 16:44:06 Тихон Тарнавский wrote:
On Wed, 18.03.2009 17:09:18 , Konstantin Matyukhin wrote:
2009/3/18 Alexander Danilov alexander.a.dani...@gmail.com:
Konstantin Matyukhin пишет:
2009/3/18 Mikhail Gusarov dotted...@dottedmag.net:
Twas brillig at 16:30:26 18.03.2009 UTC+03 when
kmatyuk...@gmail.com did gyre and gimble:

KM А новичку не все ли равно? Хоть BASIC. Дело-то не в
конкретном ЯП, KM а в общем уровне програмистской культуры. А
это только опыт и KM фундаментальные знания.

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

От языка почти не зависит. По-русски разговаривают и Сява и Сева.

Очень сильно зависит. Язык - это определяющий фактор. В
программирование - тем более.

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

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

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

Re: Perl or Python?


Aleksey Cheusov wrote:

Shell, AWK, UNIX tools, bmake (NetBSD make), Lua, Java Script.  Дальше в


Можно про bmake поподробнее, действительно ли это панацея
от gmake?

Я нашел только это
http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/devel/bmake/files/bmake.1
http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/devel/bmake/files/PSD.doc/tutorial.ms

а там говорится что это PMake.

--
С уважением, Александр Гавенко.
Компания БИФИТ.
Сайт:   www.bifit.com.ua
Тел:+38 (0562) 23-23-14, 23-31-00
E-mail: gave...@bifit.com.ua


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Тихон Тарнавский

Hello!

On Thursday 19 March 2009 01:28:20 Artem Chuprina wrote:
AP Alexander Danilov недавно высказывал желание сделать аналог SQLite на
одном из AP функциональных языков. Имхо не лучшая идея с точки зрения
эффективности, AP предпочитаю на С низкоуровневые вещи делать (ну может
еще и ностальгия у меня AP по С, не буду отрицать). Ну если напишет -
посмотрим :-)

Эээ... А где ты в задаче написания _аналога_ SQLite обнаружил низкий
уровень?

SQLite использует встроенную виртуальную машину:

Each instruction in the virtual machine consists of an opcode and up to five
operands named P1, P2 P3, P4, and P5. P1, P2, and P3 are 32-bit signed
integers. These operands often refer to registers. P2 is always the jump
destination in any operation that might cause a jump. P4 may be a 32-bit
signed integer, a 64-bit signed integer, a 64-bit floating point value, a
string literal, a Blob literal, a pointer to a collating sequence comparison
function, or a pointer to the implemantation of an application-defined SQL
function, or various other things. P5 is an unsigned character normally used
as a flag. Some operators use all five operands. Some use one or two. Some
operators use none of the operand

Или для вас работа с регистрами процессора это задача для скриптового языка?

Best regards.

Re: Perl or Python?

2009-03-19 Пенетрантность yuri . nefedov

On Wed, 18 Mar 2009, Alexander Danilov wrote:

James Brown пишет:

Alexander Danilov пишет:

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

А с чего лучше начать?! (учиться правильно программировать, точнее, если
быть честным :-[ учиться программировать)

Это очень трудный вопрос.

Но надо искать тот pdf, что с картинками. Это книга научит думать головой.
Там теория и практика.

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

Более советовать не стану, учить никогда не умел.

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

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

В таких условиях, я бы рекомендовал прочитать
Керниган Б.В., Ритчи Д.М. Язык программирования С
Это классический пример _очень_ хорошего учебника.

Phyton возможно и более хороший кандидат на звание
первый язык программирования. Но вот такой же
хорошей книги там нет. Впрочем, если Dive Into Python
пошёл, то почему бы и нет. (Кстати я тут по ошибке рекомендовал
Python Reference Manual, так то я имел в виду
Python Tutorial. Они в одной коробке идут, вот и попутал.)

Паралельно я бы порекомендовал читать Advanced Bash-Scripting
Guide. Хотя бы первые две части. А если начнете читать
Кернигана-Ричи, то в дополнение обязательно посмотрите
Брайн Керниган, Роб Пайк Unix. Программное окружение
Хотя, можно её читать и без C, наверное.

Успехов.
Ю.

Re: Perl or Python?

On Thu, 19.03.2009 00:24:50 , Aleksey Cheusov wrote:
Но _читать_ про функциональный подход, конечно же, нужно. Это
структурирует пустоту в голове. В некоторых случаях воспитывает чувство
красивого в математике и программировании. То есть, это имеет смысл по
крайней мере для педагогических воспитательных целей.
Так изначально именно об этом и шла речь.
Изначально речь шла об аргументах типа испорченные императивным
подходом, начинать образование нужно обязательно с функциональных
языков и прочем.
Нет. Такие аргументы пошли в ответ на твои не менее сомнительные
заявления об императивности 99% алгоритмов изначально от
рождения. Никакого подтверждения этим словам так и не было
предоставлено (т.к. такое подтверждение и не может быть предоставлено по
определению: это ведь в лучшем случае художественное преувеличесние).
Более того, некоторые задачи можно алгоритмизировать гораздо красивее,
если не считать их императивными от рождения. Многие -- наоборот, не
спорю. Но 99% какая-то очень уж спотолочная цифра.

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

--
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Aleksey Cheusov wrote:
Shell, AWK, UNIX tools, bmake (NetBSD make), Lua, Java Script. Дальше в

Можно про bmake поподробнее, действительно ли это панацея
от gmake?
Я считаю, что да. В последнее время сильно жалею, что вообще связался с
GNU make-ом. Смотри флейм в ru.unix.prog и мою задачу Витусу, решения
которой я так и не увидел. Смотри также вполне интересную задачу Витуса.

Впрочем, затычка очень мелкая - всего лишь наличие .for/.endfor
в bmake, но с ее помощью можно делать очень удобные штуки.
Я опять занимаюсь бессовестной саморекламой, пардон, но смотри
mk-configure на sf.net. Мои распоследние изыскания.

Что касается мануалов. Они намного меньше по объему, чем GNU
make-овские, чтение не займет много времени. И он сам по себе намного
проще и удобнее IMHO. В дополнение к ману нужно читать bsd.README от mk
скриптов. Этого достаточно. Есть еще пару ссылок на WIKI, но они мне не
очень нравятся.

Я нашел только это
http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/devel/bmake/files/bmake.1
http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/devel/bmake/files/PSD.doc/tutorial.ms

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

а там говорится что это PMake.
pmake - parallel make или 4.4BSD make. То есть, это общий корень для
всех Free/Open/NetBSD make-ов. К сожалению, в развитии они разошлись и
сейчас несовместимы друг с другом. что-либо написать портабельно на ВСЕ
bsd make-и реально, но болезненно. Не, можно, конечно, вот как раз на
том, что называлось 4.4BSD make, но это не так интересно. То же самое
касается Mk скриптов. Они немного разные. Поэтому лучше сразу bmake и
mk-files/pkgsrc-ные Mk scripts. Надежнее.

pmake в дебиане - это древняя версия NetBSD make-а.
Распоследний bmake запакетирован, кажется, только в Федоре :-(

Все тут.
ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Михаил Миронов


Twas brillig at 11:09:44 19.03.2009 UTC+02 when v...@gmx.net did gyre and 
gimble:

 AC Я опять занимаюсь бессовестной саморекламой, пардон, но смотри
 AC mk-configure на sf.net. Мои распоследние изыскания.

Там, кстати, тоже пиара нет. Даже одностраничного summary на
mk-configure.sf.net

-- 


pgpnOvKAnkPW6.pgp
Description: PGP signature

Re: Re: Debian Russian Mailing List и GMail. Ка к настроить адресат ответ а?

2009-03-19 Пенетрантность Ilya Demianov

DamirX пишет:

В Чтв, 12/03/2009 в 05:57 -0400, Mark Goldshtein пишет:

Помогите пожалуйста настроить следующую вещь:

При пользовании рассылкой, для того, что бы задать вопрос я шлю письмо
на адрес рассылки: debian-russian@lists.debian.org
Когда добрые люди мне отвечают а я хочу уточнить вопрос, то я отвечаю
уже им, в Кому стоит их адрес, а не адрес рассылки. Поэтому,
приходится подменять его руками. Иногда об этом забываешь, машинально
отправляя ответ. Тред рвётся. Возможно пропадает что-то дельное, опыт.

Надо использовать какой-нибудь более другой MUA. Например такой, который
можно научить отвечать в рассылку (утверждают, что это mutt), или такой,
которого можно явно ткнуть носом ответить в рассылку (evolution,
thunderbird), или, на худой конец, нажать ответить всем и лишнее
удалить.

Подскажите, а что подкрутить в IceDove\Thunderbird для того что в Кому:
подставлялся автоматически адресс рассылки?

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian Russian Mailing List и GMail. Как настроить адресат ответа?

Ilya Demianov пишет:
 
 Подскажите, а что подкрутить в IceDove\Thunderbird для того что в Кому:
 подставлялся автоматически адресс рассылки?
 
 

http://www.juergen-ernst.de/addons/replytolist.html


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Oleksandr Gavenko

On 2009.03.19 at 03:34:25 +0200, Aleksey Cheusov wrote:

 А типизированные переменные они не ввели случайно?

Слава богу, нет. НУ не должны быть ПЕРЕМЕННЫЕ типизированными.
Типизированными должны быть ЗНАЧЕНИЯ, и они уже и так давно таковыми
являются.
 Хочу -- int, хочу -- string|int, не хочу -- безтиповые по умолчанию.

А вот int и string - это явно один и тот же тип. SCALAR называется.

Я понимаю, когда проводят границу между scalar, tuple и list как в
Python. Но между int и string... (хотя вот  в tcl everything is string,
включая list и dictionary)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?


Mikhail Gusarov wrote:

А, всё понятно. Надеюсь, нормальный project page таки появится.


Угу SF пустой. Google по поводу mk-configure
выдал только

http://mail-index.netbsd.org/netbsd-users/2009/03/03/msg003214.html

--
С уважением, Александр Гавенко.
Компания БИФИТ.
Сайт:   www.bifit.com.ua
Тел:+38 (0562) 23-23-14, 23-31-00
E-mail: gave...@bifit.com.ua


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?


 Twas brillig at 15:16:23 19.03.2009 UTC+06 when dotted...@dottedmag.net did 
 gyre and gimble:

 MG Там, кстати, тоже пиара нет. Даже одностраничного summary на
 MG mk-configure.sf.net

 cheusov registered the Lightweight replacement for GNU autoconf
 project, 2 days ago

 А, всё понятно. Надеюсь, нормальный project page таки появится.

http://sourceforge.net/projects/mk-configure

Буквально вчера зааплоадил туда последний рилиз.

Тарболы доступны еще здесь

http://mova.org/~cheusov/pub/mk-configure/

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?


Twas brillig at 15:16:23 19.03.2009 UTC+06 when dotted...@dottedmag.net did 
gyre and gimble:

 MG Там, кстати, тоже пиара нет. Даже одностраничного summary на
 MG mk-configure.sf.net

cheusov registered the Lightweight replacement for GNU autoconf
project, 2 days ago

А, всё понятно. Надеюсь, нормальный project page таки появится.

-- 


pgp7w7aKKw2rc.pgp
Description: PGP signature

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Mishustin Alexey

Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
11:19:57 +0300:

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

Эээ... А где ты в задаче написания _аналога_ SQLite обнаружил низкий
уровень?

AP SQLite использует встроенную виртуальную машину:

AP Each instruction in the virtual machine consists of an opcode and up to
five
AP operands named P1, P2 P3, P4, and P5. P1, P2, and P3 are 32-bit signed
AP integers. These operands often refer to registers. P2 is always the jump
AP destination in any operation that might cause a jump. P4 may be a 32-bit
AP signed integer, a 64-bit signed integer, a 64-bit floating point value, a
AP string literal, a Blob literal, a pointer to a collating sequence
comparison
AP function, or a pointer to the implemantation of an application-defined SQL
AP function, or various other things. P5 is an unsigned character normally
used
AP as a flag. Some operators use all five operands. Some use one or two. Some
AP operators use none of the operand

AP Или для вас работа с регистрами процессора это задача для скриптового
языка?

1. often refer to registers не означает, что они там работают с
регистрами процессора. Это и не для C, прямо скажем, задача. Это
только на ассемблере.

2. Соответственно, если делать такую же машину на нормальном
функциональном языке, оно тоже будет often refer to registers. Но ...

3. И наконец, зачем при создании _аналога SQLite_ на функциональном
языке реализовать эту самую виртуальную машину? Это когда его пишут на
C, эту машину надо делать. А в функциональном, скорее всего, нужные
возможности предоставлены языком.

Разумеется, эмуляция ассемблерного кода на хаскеле будет работать
медленнее оригинала. Возможно - намного медленнее. А вот реализация
той же функциональности...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
-- Phil Greenspun
Including Common Lisp.
-- Robert Morris

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

3/19/2009, Artem Chuprina r...@ran.pp.ru вы писали:

А вот про Advanced Bash-Scripting Guide я бы
предостерег. Если содержание соответствует названию, то это должна быть
очень сильно не первая книжка. Если вообще. Ибо bash-специфичное
програмирование имеет смысл только если твой интерактивный шелл - bash,
и ты понимаешь, почему именно он. А если содержание не соответствует
названию, то ее не следует читать ровно по этой причине.

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

С уважением,
Алексей Мишустин

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 12:21:02 Victor Wagner wrote:
 Слава богу, нет. НУ не должны быть ПЕРЕМЕННЫЕ типизированными.
 Типизированными должны быть ЗНАЧЕНИЯ, и они уже и так давно таковыми
 являются.

А что скажете насчет ситуации с NULL в СУБД? Строгая типизация во многих СУБД 
- и такие грабли. Собственно, сам я при использовании SQLite полностью 
отказался от NULL, при  необходимости просто оперирую пустой строкой, благо в 
SQLite типизированы именно _значения_. Но вот в PostgreSQL ситуация печальнее, 
и для меня это была одна из причин для замены СУБД.

Best regards.

Re: Perl or Python?

2009-03-19 Пенетрантность yuri . nefedov

On Thu, 19 Mar 2009, Artem Chuprina wrote:

yuri.nefe...@gmail.com - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
11:20:20 +0300 (MSK):

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

y В таких условиях, я бы рекомендовал прочитать
y Керниган Б.В., Ритчи Д.М. Язык программирования С
y Это классический пример _очень_ хорошего учебника.

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

Возможно, возможно. Решать JB. Не соглашусь только, что эта книга
только про С. Там есть свой стиль. Да, на С завязанный, но всё же
достаточно общий и для других C-like языков.

y Паралельно я бы порекомендовал читать Advanced Bash-Scripting
y Guide. Хотя бы первые две части.

Эта еще куда ни шло... А вот про Advanced Bash-Scripting Guide я бы
предостерег. Если содержание соответствует названию, то это должна быть
очень сильно не первая книжка. Если вообще. Ибо bash-специфичное
програмирование имеет смысл только если твой интерактивный шелл - bash,
и ты понимаешь, почему именно он. А если содержание не соответствует
названию, то ее не следует читать ровно по этой причине.

Именно поэтому - первые две части (Почему программировать в shell?
и Basics). Основы и минимум башизмов. А если пойдет, так там далее
читать и читать. :)

Ю.

Re: Perl or Python?

Aleksey Cheusov - Oleksandr Gavenko  @ Thu, 19 Mar 2009 11:09:44 +0200:

 AC pmake в дебиане - это древняя версия NetBSD make-а.
 AC Распоследний bmake запакетирован, кажется, только в Федоре :-(

Слушай, вот ты пиаришь тут программу, которой в дистрибутиве
нет.  А почему ее нет в дистрибутиве, если ты ее тут пиаришь?

Ну хорошо, почему тут нету строчки для sources.list?

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

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Юзер упорствует в хождении по граблям. Образовавшиеся шишки он считает
трудовыми мозолями. (С)энта


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Oleksandr Gavenko

А типизированные переменные они не ввели случайно?

Слава богу, нет. НУ не должны быть ПЕРЕМЕННЫЕ типизированными.
Виктор. Наличие типизированных переменных в языке - это один из
важнейших классификационных признаков языков программирования.
При создании больших программ их наличие очень хорошо сказывается на
надежности создаваемого ПО. Это азбука!

В Pike-е, например, есть типы int, string, set (параметризованное
множество), map (параметризованный ассоциативный массив) и др., а также
mixed, который может хранить значение любого типа, включая, например,
объект или функционал (почти замыкание, да). Это нормальный, грамотный,
достаточно широко распространенный и известный подход. То, что в
наиболее распространенных скриптовых языках сейчас этого нет не ставит
крест на подходе как таковом.
В 70-х народ на PL/1 писал. И где сейчас PL/1?

Типизированными должны быть ЗНАЧЕНИЯ, и они уже и так давно таковыми
являются.
Хочу -- int, хочу -- string|int, не хочу -- безтиповые по умолчанию.

А вот int и string - это явно один и тот же тип. SCALAR называется.
Нет. Это полная ерунда. scalar/vector - это никакой не тип.

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian Russian Mailing List и GMail. Как настроить адресат ответа?


Михаил Миронов wrote:


http://www.juergen-ernst.de/addons/replytolist.html



Please keep in mind that this whole thing is a hack - it 
uses some timeouts to change the address, and so it takes 
1.5 seconds after the reply window is opened until the 
address is changed and the cursor/focus is back to the text 
editor.


С этого же сайта.
--
С уважением, Александр Гавенко.
Компания БИФИТ.
Сайт:   www.bifit.com.ua
Тел:+38 (0562) 23-23-14, 23-31-00
E-mail: gave...@bifit.com.ua


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Vasily Chekalkin

2009/3/19 Aleksey Cheusov v...@gmx.net:
   А типизированные переменные они не ввели случайно?

 Слава богу, нет. НУ не должны быть ПЕРЕМЕННЫЕ типизированными.
 Виктор. Наличие типизированных переменных в языке - это один из
 важнейших классификационных признаков языков программирования.
 При создании больших программ их наличие очень хорошо сказывается на
 надежности создаваемого ПО. Это азбука!

А вот это к какому типу относится:

 my Int $a = 5; say $a
5
 my Int $a = foo; say $a
Type mismatch in assignment.
 my Int $a = 42; my $b = $a; say $b
42
 my Int $a = 42; my $b = $a; $b = foo; say $b
foo

?

-- 
Bacek.

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 13:18:50 Artem Chuprina wrote:
  AP А что скажете насчет ситуации с NULL в СУБД? Строгая типизация во
  AP многих СУБД - и такие грабли.

 А где грабли-то?

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

Трехзначная логика получается. И на практике, например, приходится 
обрабатывать _две_ ситуации - строка есть NULL или пустая строка, при том, что 
с точки зрения приложения эти ситуации зачастую различить нельзя.

  AP Собственно, сам я при использовании SQLite полностью отказался от
  AP NULL, при необходимости просто оперирую пустой строкой,

 А вот это - грабли...

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

Best regards.

Re: Perl or Python?

2009-03-19 Пенетрантность Михаил Миронов

On 2009.03.19 at 12:08:32 +0200, Aleksey Cheusov wrote:

А типизированные переменные они не ввели случайно?

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

При создании больших программ их наличие очень хорошо сказывается на

Скорее, это служит признаком того, что этот язык НЕЛЬЗЯ использовать для
создания больших программ. Его ниша - маленькие кусочки, критичные по
скорости выполнения.

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

надежности создаваемого ПО. Это азбука!

Это не азбука, это катехезис. А я - атеист.

Кстати, создание больших проектов НЕИЗБЕЖНО приводит к тому что
появляются те или иные конструкции для обхода строгой типизации.

Например, система template в C++ и STL-евские контейнеры.
Или общий предок TObject в Turbo Vision (по-моему и в
ObjC что-то аналогичное есть).

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

А вот int и string - это явно один и тот же тип. SCALAR называется.
Нет. Это полная ерунда. scalar/vector - это никакой не тип.

А что же это? Если над ними есть вполне определенные наборы операций?

В вышепоскипанном ты рассматривал в качестве типов set и map - чем
vector хуже set? В том же STL - это сущности одного и того же порядка.
Не нравится слово vector, можно использовать sequence (правда, тогда те,
кто читал Вирта поймут неправильно. У Вирта sequence ближе к generator
чем к vector).

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian Russian Mailing List и GMail. Как настроить адресат ответа?

Oleksandr Gavenko пишет:
 Михаил Миронов wrote:

 http://www.juergen-ernst.de/addons/replytolist.html

 
 Please keep in mind that this whole thing is a hack - it uses some
 timeouts to change the address, and so it takes 1.5 seconds after the
 reply window is opened until the address is changed and the cursor/focus
 is back to the text editor.
 
 С этого же сайта.

Ну да. Но остальные версии требуют патча к Thunderbird. У меня
Thunderbird используется под оффтопиком - там патча нет. Под топиком
просто не знаю как обстоят дела. Выйдет 3 Thunderbird - можно будет
использовать человеческие решения.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

On 2009.03.19 at 13:27:57 +0300, Alexey Pechnikov wrote:

Hello!

On Thursday 19 March 2009 13:18:50 Artem Chuprina wrote:
AP А что скажете насчет ситуации с NULL в СУБД? Строгая типизация во
AP многих СУБД - и такие грабли.

А где грабли-то?

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

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

Трехзначная логика - это глубокая концептуальная ошибка создателей SQL.
Логика должна быть ЧЕТЫРЕХЗНАЧНОЙ - да, нет, не знаю, не важно.

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

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

В perl и javascript значение undefined есть, и оно там крайне полезно.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

On 2009.03.19 at 13:30:52 +0300, James Brown wrote:

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

Вопрос-то был совершенно не ламерский.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Alexey Pechnikov - debian-russian@lists.debian.org  @ Thu, 19 Mar 2009 
12:50:43 +0300:

  Слава богу, нет. НУ не должны быть ПЕРЕМЕННЫЕ типизированными.
  Типизированными должны быть ЗНАЧЕНИЯ, и они уже и так давно таковыми
  являются.

 AP А что скажете насчет ситуации с NULL в СУБД? Строгая типизация во
 AP многих СУБД - и такие грабли.

А где грабли-то?

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

 AP Собственно, сам я при использовании SQLite полностью отказался от
 AP NULL, при необходимости просто оперирую пустой строкой,

А вот это - грабли...  См. также http://city-rat.livejournal.com/739470.html

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

/dev/null-транспортировка


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?


Twas brillig at 12:58:35 19.03.2009 UTC+03 when r...@ran.pp.ru did gyre and 
gimble:

 AC Нет, они не антонимы.  Просто _advanced_ bash scripting подразумевает
 AC очень изрядную заточку именно под bash.

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

-- 


pgplE5szWlpyU.pgp
Description: PGP signature

Re: Perl or Python?

Alexey Pechnikov - debian-russian@lists.debian.org  @ Thu, 19 Mar 2009 
13:27:57 +0300:

   AP А что скажете насчет ситуации с NULL в СУБД? Строгая типизация во
   AP многих СУБД - и такие грабли.
 
  А где грабли-то?
 
  Там, конечно, от этого появляются грабли в теории, но это грабля в
  теории - потому что на практике оказалось, что не в каждом интересном
  тупле удается определить все значения.

 AP Трехзначная логика получается. И на практике, например, приходится
 AP обрабатывать _две_ ситуации - строка есть NULL или пустая строка,
 AP при том, что с точки зрения приложения эти ситуации зачастую
 AP различить нельзя.

Если с точки зрения приложения ситуации различить нельзя, то приложение
решает НЕ ТУ задачу.

   AP Собственно, сам я при использовании SQLite полностью отказался от
   AP NULL, при необходимости просто оперирую пустой строкой,
 
  А вот это - грабли...

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

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

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

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Вам правду резать или кусочком?
Кнышев


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 13:42:39 Artem Chuprina wrote:
Пустая строка - это не то же самое, что значение не определено.
Пустая строка - это определенное значение. Нет, конечно, если таково
ограничение языка, на котором сделано приложение, то можно все приводить
к пустой строке. Это просто значит, что грабли переместятся в другое
место.

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

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

Стандартная задачка из статистики про урну/урны с шарами. Вытаскиваем белый
ИЛИ черный шар. Что значит, цвет шара не определен? А вот когда при сборе
данных с датчиков подобное безобразие запихивают в базу, нормальная ситуация.

Best regards.

Re: Perl or Python?

2009-03-19 Пенетрантность James Brown

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian Russian Mailing List и GMail. Как настроить адресат ответа?

2009-03-19 Пенетрантность Ilya Demianov


Михаил Миронов пишет:

Ilya Demianov пишет:
  

Подскажите, а что подкрутить в IceDove\Thunderbird для того что в Кому:
подставлялся автоматически адресс рассылки?





http://www.juergen-ernst.de/addons/replytolist.html


  

Спасибо, то что нужно.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

 AC Я опять занимаюсь бессовестной саморекламой, пардон, но смотри
 AC mk-configure на sf.net. Мои распоследние изыскания.

 Там, кстати, тоже пиара нет. Даже одностраничного summary на
 mk-configure.sf.net

Пиар внутри. Смотри README и TODO.
Полная документация в манах на mkc_check_xxx программы
и внутри configure.mk.
Что касается mk-configure.sf.net.
Пиару мне еще учиться и учиться на самом деле :-/
И в этом деле принимается любая помощь ;-)

Вот например, очень было бы здорово увидеть пакеты bmake и mk-files
в Debian-е ;-)

P.S.
А. Ты меня все-таки вытащил из /dev/null? :-)

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

On 2009.03.19 at 00:27:41 +0200, Aleksey Cheusov wrote:

  Но вот нифига не получилось. Не пишут виндусовые сисадмины скриптов на
  JScript.
 
 Продвинутые, говорят, пишут на PowerShell.

Тому PowerShell без году неделя. А WSH уже 10 лет скоро.
В начале, когда он только появился, тоже многие продвинутые в него
игрались. Потом бросили и вернулись к CMD.EXE. C PowerShell, боюсь, то
же самое будет.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

On 2009.03.19 at 14:03:35 +0300, Alexey Pechnikov wrote:

 Стандартная задачка из статистики про урну/урны с шарами. Вытаскиваем белый 
 ИЛИ черный шар. Что значит, цвет шара не определен?

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



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 14:22:56 Victor Wagner wrote:
  Стандартная задачка из статистики про урну/урны с шарами. Вытаскиваем
  белый ИЛИ черный шар. Что значит, цвет шара не определен?

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

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

Best regards.

Re: Perl or Python?

On 2009.03.19 at 13:52:13 +0300, Alexey Pechnikov wrote:

 Hello!
 
 On Thursday 19 March 2009 13:37:37 Victor Wagner wrote:
   Трехзначная логика получается. И на практике, например, приходится
 
  Трехзначная логика - это глубокая концептуальная ошибка создателей SQL.
  Логика должна быть ЧЕТЫРЕХЗНАЧНОЙ - да, нет, не знаю, не важно.
 
  А в SQL не знаю и не важно обозначаются одним и тем же символом.
 
 Создав таблицу сущностей и ссылаясь на нее, можно сделать хоть пятизначную 
 логику - да, нет, не знаю, не важно, не уверен. Создавать предопределенные 

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



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 13:37:37 Victor Wagner wrote:
Трехзначная логика получается. И на практике, например, приходится

А в SQL не знаю и не важно обозначаются одним и тем же символом.

Создав таблицу сущностей и ссылаясь на нее, можно сделать хоть пятизначную
логику - да, нет, не знаю, не важно, не уверен. Создавать предопределенные
сущности есть ошибка. Надо же так извратить алгебру множеств, что в любом,
даже пустом множестве есть элемент NULL, но он не учитывается. Как, по-
вашему, описывать это безобразие? Что дает пересечение двух множеств, одно из
которых пустое, но оба содержат NULL - истинное пустое множество или пустое
множество с NULL? Спасибо SQLite, автор которого знает мат. аппарат и позволил
избавиться от вышеописанного безобразия.

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

В perl и javascript значение undefined есть, и оно там крайне полезно.

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

Best regards.

Re: Perl or Python?


   А типизированные переменные они не ввели случайно?

 Слава богу, нет. НУ не должны быть ПЕРЕМЕННЫЕ типизированными.
 Виктор. Наличие типизированных переменных в языке - это один из
 важнейших классификационных признаков языков программирования.
 При создании больших программ их наличие очень хорошо сказывается на
 надежности создаваемого ПО. Это азбука!

 А вот это к какому типу относится:
Это именно то, о чем я и говорил.
Точно такое же есть в Pike-е.

Pike v7.6 release 93 running Hilfe v3.5 (Incremental Pike Frontend)
] int a=5; write((string) a);
5(1) Result: 1
] a = mama; write (a);
Compiler Error: 1:Bad type in assignment.
Compiler Error: 1:Expected: int
Compiler Error: 1:Got : string
Compiler Error: 1:Bad argument 1 to safe_write.
Compiler Error: 1:Expected: function(string, mixed ... : int)
Compiler Error: 1:Got : function(int : void | mixed)
] a=42; mixed b=a; write((string) b);
(2) Result: 42
42(3) Result: 2
] b=mama; write (b);
(4) Result: mama
mama(5) Result: 4

 my Int $a = 5; say $a
 5
 my Int $a = foo; say $a
 Type mismatch in assignment.
 my Int $a = 42; my $b = $a; say $b
 42
 my Int $a = 42; my $b = $a; $b = foo; say $b
 foo

 ?

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 13:08:32 Aleksey Cheusov wrote:
Слава богу, нет. НУ не должны быть ПЕРЕМЕННЫЕ типизированными.

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

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

Best regards.

Re: Perl or Python?

Mishustin Alexey - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
12:31:51 +0300:

А вот про Advanced Bash-Scripting Guide я бы предостерег. Если
содержание соответствует названию, то это должна быть очень сильно не
первая книжка. Если вообще. Ибо bash-специфичное програмирование
имеет смысл только если твой интерактивный шелл - bash, и ты
понимаешь, почему именно он. А если содержание не соответствует
названию, то ее не следует читать ровно по этой причине.

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

Нет, они не антонимы. Просто _advanced_ bash scripting подразумевает
очень изрядную заточку именно под bash.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Это неправильный шелл. В нем дают неправильный перл. (С)энта

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

А типизированные переменные они не ввели случайно?

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

Шъерт побъери(С) Вы там наверное в одной норе живете.

Нет, нет и нет. Смотри Pike или Objective-C как примеры.
Modula-3, кажется тоже. Да их полно на самом деле.

При создании больших программ их наличие очень хорошо сказывается на

Скорее, это служит признаком того, что этот язык НЕЛЬЗЯ использовать для
создания больших программ. Его ниша - маленькие кусочки, критичные по
скорости выполнения.
См. выше.

надежности создаваемого ПО. Это азбука!

Это не азбука, это катехезис. А я - атеист.
Аналогично. Но это нынче не в моде.

Кстати, создание больших проектов НЕИЗБЕЖНО приводит к тому что
появляются те или иные конструкции для обхода строгой типизации.
Не то, чтобы неизбежно...

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

А вот int и string - это явно один и тот же тип. SCALAR называется.
Нет. Это полная ерунда. scalar/vector - это никакой не тип.

А что же это? Если над ними есть вполне определенные наборы операций?

В вышепоскипанном ты рассматривал в качестве типов set и map - чем
vector хуже set?
Тем, что множество - это множество, а вектор - это вектор и у них
совершенно разный набор базовых операций. В массив нельзя _эффективно_
вставить новый эелемент, при условии, что там его нет, а в множество
можно. Я уж не говорю, что множество - одно из базовых понятий при
проектировании алгоритмов наряду с ассоциативными массивами, просто
массивами, списками и прочими. Но это разные изначально разные структуры
данных. Мы тут какую ерунду 1-ого курса перемалываем, тебе не кажется?

Все это прекрасно расписано на википедии.
http://en.wikipedia.org/wiki/List_of_data_structures

В том же STL - это сущности одного и того же порядка.
Не нравится слово vector, можно использовать sequence (правда, тогда те,
кто читал Вирта поймут неправильно. У Вирта sequence ближе к generator
чем к vector).
В последний раз я Вирта читал в лучшем случае лет 15 назад (конечно, не
все). Может, забыл, где у него sequence как generator?

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
13:52:13 +0300:

AP Надо же так извратить алгебру множеств, что в любом, даже пустом
AP множестве есть элемент NULL, но он не учитывается. Как, по-
AP вашему, описывать это безобразие? Что дает пересечение двух
AP множеств, одно из которых пустое, но оба содержат NULL - истинное
AP пустое множество или пустое множество с NULL? Спасибо SQLite, автор
AP которого знает мат. аппарат и позволил избавиться от вышеописанного
AP безобразия.

В данном случае алгебра множеств оказалась не ахти как применимой к
жизни. Надо честно это признать. Да, разумеется, мы можем ввести
сущность ошибка, но показания прибора нам этот ввод не даст. Если мы
считаем, что это повод не заносить данные в таблицу - мы говорим not
null, и писатель вынужден заносить эти данные в другую таблицу или не
заносить вообще. Мы даже можем нарисовать триггер, который сам будет
заносить эти данные в таблицу ошибок. Но тут мы можем наступить на
другие грабли. Если в реальности у нас в эксперименте один датчик
сломался, мы тем не менее обычно хотим получить данные с остальных
датчиков. И обсчитывать их, насколько сможем. При этом заносить эти
данные в другое место неразумно - тогда все обсчитывалки должны
учитывать еще и это другое место, и ради того, чтобы избежать
искусственного NULL, мы вынуждены не менее искусственно объединять
несколько таблиц при обсчете.

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

Дело не в кривизне рук разработчиков СУБД. Дело в том, что жизнь
сложнее Ваших представлений о ней...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

If a `religion' is defined to be a system of ideas that contains
unprovable statements, then Godel taught us that mathematics is not
only a religion, it is the only religion that can prove itself to be
one.
-- John Barrow

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Владимир Ступин

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

 В perl и javascript значение undefined есть, и оно там крайне полезно.

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

http://ru.wikipedia.org/wiki/%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D0%B7%D0%BD%D0%B0%D1%87%D0%BD%D0%B0%D1%8F_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0
http://en.wikipedia.org/wiki/Multi-valued_logic

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

19 марта 2009 г. 17:19 пользователь Aleksey Cheusov v...@gmx.net написал:

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

 С/C++ - по определению языки небезопастные.

 Pike, например, язык динамический и безопастный

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

 Это безсмысленно.

Вы осознанно в приставке заменяете с на з? Просто уже не первый
раз встречаю людей, которые начитались беллетристики с сайта
www.vodaspb.ru. Там часто можно встретить такую орфографию. В
частности, вот тут:
http://www.vodaspb.ru/russian/files/20040510-about_KOB.html, есть
раздел ПОЯСНЕНИЕ: О грамматике внизу, где объясняются взгляды на
правильность именно такой орфографии.

Re: Perl or Python?

 Mikhail Gusarov wrote:
  А, всё понятно. Надеюсь, нормальный project page таки появится.
 
 Угу SF пустой. Google по поводу mk-configure
 выдал только

Блин, ну вы как дети, честное слово.
http://sourceforge.net/projects/mk-configure
Любая помощь в организации WEB/WIKI странички принимается.

 http://mail-index.netbsd.org/netbsd-users/2009/03/03/msg003214.html
Там ссылка на старую версию.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?


Twas brillig at 11:38:06 19.03.2009 UTC+02 when v...@gmx.net did gyre and 
gimble:

 AC http://sourceforge.net/projects/mk-configure
 AC Буквально вчера зааплоадил туда последний рилиз.

Я про это: http://mk-configure.sourceforge.net/

-- 


pgpGiXB3Ft5WG.pgp
Description: PGP signature

Re: Perl or Python?

2009-03-19 Пенетрантность Konstantin Matyukhin

On 2009.03.19 at 14:35:40 +0300, Alexey Pechnikov wrote:

 Hello!
 
 On Thursday 19 March 2009 14:22:56 Victor Wagner wrote:
   Стандартная задачка из статистики про урну/урны с шарами. Вытаскиваем
   белый ИЛИ черный шар. Что значит, цвет шара не определен?
 
  Это значит, что в момент вытаскивания выключился свет, и отличить белый
  шар от черного не удалось.
 
 А это аппаратная ошибка, данные не получены, следует исправить аппаратную 
 проблему и повторить эксперимент. Сохранить эти данные, воспользовавшись 

Интересно, каким это образом я могу повторить эксперимент, например, в
метеорологии? Если мне не удалось определить температуру воздуха в 3
часа ночи, потому что белый медведь сожрал психрометр, то когда я
психрометр заменю, это будет отсчет уже не на 3 часа ночи, а на 6 утра.

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

Опять же, психрометр он сожрал, а до анемометра и барометра не добрался.
Потому что барометр в доме, а анемометр на крыше. Соответственно данные
по скорости ветра и давлению за 3 часа у меня есть.

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

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

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

Например, что писать в поле цвет волос, если клиент лыс?

Что писать в поле отпечаток указательного пальца левой руки, если
клиенту эту левую руку оторвало в одной из прошедших войн?

Другая часть лакун объясняется тем, что СЕЙЧАС мы этой информации не
знаем (вроде цвета шара в момент, когда электричество отключено), но
ПОТОМ можем узнать (повторить эксперимент).

Вопрос в том, что повторить эксперимент мы можем ПОТОМ, а решения на
основе собранных данных надо принимать СЕЙЧАС. 

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

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



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009/3/19 Alexey Pechnikov pechni...@mobigroup.ru:
 Стандартная задачка из статистики про урну/урны с шарами. Вытаскиваем белый
 ИЛИ черный шар. Что значит, цвет шара не определен? А вот когда при сборе
 данных с датчиков подобное безобразие запихивают в базу, нормальная ситуация.
Г-ди, какая же каша у человека в голове. Извини, Алексей. Ничего личного.

-- 
С уважением,
Константин Матюхин

Re: Perl or Python?

Слава богу, нет. НУ не должны быть ПЕРЕМЕННЫЕ типизированными.

В каком месте сказывается?
Во всех.

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

С/C++ - по определению языки небезопастные. Сегфолтятся они благодаря
наличию в них преобразования типов указателей и ручной работе с памятью.

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

Ничего, кроме скорости выполнения и упрощения
компилятора/интерпретатора типизация переменных не дает.
Наглое и подлое вранье! Разницу между compile-time и run-time проверками
знаем? А разницу в цене этих проверок?

При выполнении кода и при типизации _значений_ вы можете проверить,
Угу. Детский сад. Спасибо за откровение.

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

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
14:03:35 +0300:

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

AP Стандартная задачка из статистики про урну/урны с
AP шарами. Вытаскиваем белый ИЛИ черный шар. Что значит, цвет шара не
AP определен? А вот когда при сборе данных с датчиков подобное
AP безобразие запихивают в базу, нормальная ситуация.

У Вас либо бывает такое в жизни (и тогда Вы, гм, можете у специалиста в
предметной области выяснить, что это значит), либо не бывает, и тогда Вы
пишете констрейнт not null. А так, чтобы что значит цвет шара не
определен, но записи с NULL в базе, тем не менее, есть - это ошибка в
программе. И от того, что в качестве NULL используется пустая строка,
суть ошибки не меняется.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

There's no sense in being precise, when you don't even know what
you're talking about.
-- John von Neumann

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

AC pmake в дебиане - это древняя версия NetBSD make-а.
AC Распоследний bmake запакетирован, кажется, только в Федоре :-(

Слушай, вот ты пиаришь тут программу, которой в дистрибутиве
нет. А почему ее нет в дистрибутиве, если ты ее тут пиаришь?

Ну хорошо, почему тут нету строчки для sources.list?
Потому что я плохо знаю Debian. Я по-моему в этом уже признавался. К
тому же у меня etch и никаких lenny у меня в ближайшие годы не
предвидится. То есть любителям source.list все равно придется
пересобирать самим. Но я думаю над этим. Остальное свое тоже хотел бы
выложить в виде готовых пакетов. А проектов у меня много развелось. Все
никак не соберусь. Но по ряду причин было бы правильнее, если бы этим
занялся профессиональный Debian Developer. Как апстрим developer
дистрибутиву Debian могу сказать большое спасибо, от его пользователей и
пакетировщиков я получаю бОльшую часть замечаний и сообщений об ошибках.

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

http://mova.org/~cheusov/pub/pkgsrc-pics/OKI-6.jpg

Готов помочь? ;-)

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

yuri.nefe...@gmail.com - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
11:20:20 +0300 (MSK):

Это очень трудный вопрос.

Начать следует с чтения теории и применять её на практике.
Советую прочесть SICP - Структура и интерпретация компьютерных программ.
Книжка выпущена на русском в бумажном виде, есть в электронном виде
по-русски - sicp.pdf
Но надо искать тот pdf, что с картинками. Это книга научит думать головой.
Там теория и практика.

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

Более советовать не стану, учить никогда не умел.

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

y Паралельно я бы порекомендовал читать Advanced Bash-Scripting
y Guide. Хотя бы первые две части. А если начнете читать
y Кернигана-Ричи, то в дополнение обязательно посмотрите
y Брайн Керниган, Роб Пайк Unix. Программное окружение
y Хотя, можно её читать и без C, наверное.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Чушь для ресниц (С)энта

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Немного не внимательно вы перочитали. Наличие перевода как такового, ещё не
гарантирует возможности этот перевод получить. По крайней мере в то время
когда начинал я.
Мир Лиспа переведена на русский в 90-м году. Когда начитал ты, эта
книга уже наверняка была ;-) Есть еще теоретическая книга
Функциональное программирование, тоже переводная, IIRC 93-года.
SICP вообще начала 80-х, но только на английском, на русский
переведена совсем недавно. В открытом доступе тоже относительно недавно.

Да, кстати, по SICP есть даже видеолекции, дядечки из MIT, одного из
авторов. На английском естественно. Вот мой коллега (не программист по
образованию) смотрит и балдеет.

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Нет. Такие аргументы пошли в ответ на твои не менее сомнительные
заявления об императивности 99% алгоритмов изначально от
рождения. Никакого подтверждения этим словам так и не было
предоставлено (т.к. такое подтверждение и не может быть предоставлено по
определению: это ведь в лучшем случае художественное преувеличесние).
Достаточно открыть какого-нибудь Сэджвика и убедиться в этом наглядно.
На пальцах посчитать так сказать.

functional algorithms - это активно исследуемая тема. Ссылки я уже
приводил. В 95-м году построить систему почти всегда (но есть не для
всех исследуемых в диссертации задач) эффективно реализует
примитивнейшие алгоритмы, записанные в функциональном виде, придуманные
в 60-х! При всем уважении -- это очень странный подход.

Могу согласиться, что дело
не столько в самом императивном подходе, сколько в том, _как_ их ему
обучали. Но эти люди действительно были испорчены таким обучением.
Вопрос КАК преподавать программирование - это отдельный, гораздо более
общий вопрос. Конечно, у меня есть по этому поводу мнение...

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность DamirX

В Чтв, 19/03/2009 в 17:43 +0500, Владимир Ступин пишет:

  С/C++ - по определению языки небезопастные.
 
  Pike, например, язык динамический и безопастный
 
 Первую ошибку проигнорировал, думал может опечатались. После второй
 решил сказать - правильно писать безопасный, без буквы т.
это, видимо, как-то с пастью связано.

--
DamirX



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Тихон Тарнавский


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

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

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

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

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

On Thu, 19.03.2009 11:56:37 , Aleksey Cheusov wrote:

Более того, некоторые задачи можно алгоритмизировать гораздо красивее,
если не считать их императивными от рождения.
Некоторые - да. Например, когда речь идет о _примитивной_ обработке
рекурсивной структуры данных, скажем, дерева или списка. Это и есть
примерно 1%, хотя, если честно, гораздо меньше. ФП в лисповском
понимании не представляет НИКАКИХ инструментов для обработки графов,
например. А графы - это я даже не знаю, сколько процентов задач.
Давай всё-таки не будем игнорировать разницу между утверждениями 99%
алгоритмов -- императивные и 1% алгоритмов -- функциональные. Даже
если второе верно, то не станешь же ты утверждать, что других парадигм
вообще не существует или что они входят в этот же 1% алгоритмов?

Опять же: я не спорю, что 99% задач (и даже больше) можно решить
императивным подходом. Я лишь говорю, что далеко не для 99% именно
этот подход окажется оптимальным. Пример, который я лучше всего знаю:
тот самый внутренний язык ABBYY, о котором я говорил выше. Его
задача -- поиск плавающих полей на документе, с целью их последующего
распознавания. Изначально эта задача решалась на C/C++ (это было ещё
до меня). Со временем стало понятно, что нужен свой язык, который
реализовали, насколько я знаю, на тех же C/C++. Язык менялся на
протяжении времени, постепенно всё лучше затачиваясь под свои задачи;
я застал одно фундаментальное изменение и множество косметических. Но
ни в одной из реализаций я не назвал бы этот язык императивным даже
приблизительно.

Они настолько привыкли мыслить линейно, что подняться над задачей и
оценить картину в целом, а не только прокладывать отдельные маршруты,
были не в состоянии; а там без этого никак.
Способность человека подняться над задачей - не зависит от того, что
он предпочитает, функциональный или императивный подход. Я, например,
предпочитаю декларативный, если это возможно. И это НИКАК не связано с
функциональщиной в общем случае. Умею я подняться над задачей в этом
случае?
Мы ведь говорим не о предпочтениях, а об обучении, верно? ФП же, снова
повторюсь, это только пример, и его многие советуют, на мой взгляд,
ещё и потому, что хороших книг по нему больше, чем по тому же
логическому. Но вот плохих по обоим этим подходам явно меньше, чем по
императивному, даже в процентном отношении. Да и по декларативному
тоже меньше, как бы этот термин ни понимать (а его в любом понимании
императивному противопоставляют в той или иной степени). Это, на мой
взгляд, тоже о чём-то говорит.

--
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Aleksey Cheusov пишет:

[skip]

Есть, конечно, красивые примеры, например ленивые списки, очень красиво,
и очень здорово, но я что-то не видел из аггитирующих за лисп фанатов
Lazy Lisp. В основном Common Lisp пропогандируют. Ленивые списки на
CL/Scheme - это гламурненко, но это можно сделать на любом динамическом
императивном ЯП, на ЛЮБОМ. Лисп и Algol60 сделали свое дело 49(!!!) лет
назад.

Только вот пользователи лиспа об этом не в курсе, в последнее время особенно
тупять,
завалили уже дебиан cl-* пакетами, ретрограды...

Но _читать_ про функциональный подход, конечно же, нужно. Это
структурирует пустоту в голове. В некоторых случаях воспитывает чувство
красивого в математике и программировании. То есть, это имеет смысл по
крайней мере для педагогических воспитательных целей.

Так изначально именно об этом и шла речь.

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

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

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Aleksey Cheusov пишет:

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

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

Некоторые - да. Например, когда речь идет о _примитивной_ обработке
рекурсивной структуры данных, скажем, дерева или списка. Это и есть
примерно 1%, хотя, если честно, гораздо меньше. ФП в лисповском
понимании не представляет НИКАКИХ инструментов для обработки графов,
например. А графы - это я даже не знаю, сколько процентов задач.

Это вы не под тем углом зрения смотрите на лисп.
У меня на этапе изучения лиспа было очень яркое впечатления от одной очень
мелкой задачки, которая была решена на лиспе. Надо было транспонировать матрицу.
Решение состояло из вызова 3-х(трёх) функций, которые не имеют никакого
отношения
к матрицам, вообще никакого. То есть ни циклов, ничего такого, просто 3 строки,
в каждой
вызов одной функции, вложенный в другую. В лиспе также нет НИКАКИХ инструментов
для обработки матриц.
Делайте выводы.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?


Victor Wagner пишет:

On 2009.03.18 at 22:57:36 +0200, Eugene V. Lyubimkin wrote:


Толстожопые и уродливые python и perl учить не надо. Вообще.

Ага, их, наверное, bmake, Lua и JavaScript заменят. На Unix-системе :/.


Попытаться заменить perl javascript-ом - идея достаточно интересная.
Фактически это сводится к разработать такую объектную модель, которая
бы позволяла работать со всеми базовыми API Unix, с которыми умеет работать
Perl


Newlisp - это как раз попытка сделать новый perl, но с перлом в его нише трудно
соревноваться. У перла уже есть много доступного кода.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Aleksey Cheusov пишет:

AC Shell, AWK, UNIX tools, bmake (NetBSD make), Lua, Java Script. Дальше в
AC любом порядке Oberon2, Scheme, Forth, TCL, Haskel, C, Oz. Forth, TCL и
AC Scheme как примеры языков с минимальным базисом. Туда же, в принципе, и
AC Lua можно отнести. Но он более, чем пригоден для практических дел,
AC хороший баланс простоты дизайна, отличной скорости интерпретатора и
AC высокоуровневости. C - ну куда же без него в UNIX-е. Forth - экзотика,
AC но... он как Черный Квадрат Малевича. В большинстве случаев бесполезен,
AC но знать надо, для полноты картины так сказать.

AC Толстожопые и уродливые python и perl учить не надо. Вообще.

Ога, давайте функциональную парадигму изучать на примере shell,

А давайте не будем передергивать. shell - это классичяеский UNIX way.
Так называемая old UNIX school. И слово old здесь не означает устареыший
и неактуальный сегодня.

а декларативную - на примере make

Да, будем. Прекрасный пример декларативного прграммирования. Особенно
если взять не GNU make, а BSD make-и и особенно их Mk скрипты. Мы это
горячо обсуждали недавно в fido7.ru.unix.prog.
Free/OpenBSD-шные порты и NetBSD-ный pkgsrc - логичное и очень хорошее
продолжение той же традиции.

и awk...

awk - это отдельная парадигма программирования. Называется data-driven
или программирование от состояний. Лично мне она ОЧЕНЬ нравится.
И она тоже есть, и она отлично работает. Даже сегодня.
Не смотря на очевидные ограничения этого языка.
Особенно, если к awk-у добавить модули, как есть у всех современных ЯП.
См. мой проект http://sf.net/projects/runawk

Если к awk добавить модули, то лучше использовать cl-awk. :)

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Владимир Ступин

Даже если второе верно, то не станешь же ты утверждать, что других
парадигм вообще не существует
Конечно, не стану. И haskell и aldor и erlang и oz и т.д. изучать нужно
и весьма полезно. _Как минимум_ мозг размять. Но не нужно предлагать их
в качестве безальтернативного первого ЯП. Эта мысль совсем не бесспорна.

или что они входят в этот же 1% алгоритмов?

Опять же: я не спорю, что 99% задач (и даже больше) можно решить
императивным подходом. Я лишь говорю, что далеко не для 99% именно
этот подход окажется оптимальным. Пример, который я лучше всего знаю:
тот самый внутренний язык ABBYY, о котором я говорил выше.
Абсолютное большинство проблемно-ориентированных языков, с которыми по
работе (Invention Machine corp.) приходится сталкиваться мне --
декларативные. Но при этом к функциональщине ни один их них не имеет
никакого отношения. А вот реализация практически всегда проще делается с
помощью императивных ЯП. Есть редкие исключения.

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

Чем-то до боли знакомым повеяло.

@inproceedings{cheusov_wre,
author= {Aleksey Vladimirovich Cheusov},
title = {The word-based regular expressions in Computational Linguistics},
booktitle = {Proceedings of the 7th International conference, Pattern
Recognition and Information},
pages = {208--213},
volume= {1},
year = {2003},
location = {Minsk},
}

Плюс еще finite state transducers и многое многое другое...

А самая трудная категория обучаемых -- это как раз были люди,
испорченные императивным подходом (в данном случае я отвечаю за свои
слова).
Ну вот опять, испорченные императивным подходом... Может, они были
просто испорченные, Безотносительно имеративного подхода?
Если бы ты при цитировании не проигнорировал мою классификацию, то
было бы видно, что корреляция достаточно убедительная. Повторюсь:
возможно проблема в том, _как_ их учили. Но вот в учебниках по
императивным языкам я эту проблему видел массово. Когда я преподавал
основы Си, я каждую свою лекцию писал с нуля, потому что то, что мне
дали, не удовлетворило меня ни в какой своей части. А вот лекции и
учебники по функциональному или логическому программированию, которые
я видел позже, не обладали этим недостатком за единственным
исключением.
Учить нужно преимущественно не конкретным ЯП, и не только парадигмам, в
них заложенным. Но еще и правильному дизайну и общей культуре
программирования. И нет, правильный дизайн - это никакой не UML. И
делать это можно с помощью open source. Open Source - это Большая
Школа. И этим можно и нужно было бы воспользоваться, вовлекая студентов
во всякие программы типа SoC (туда и некоторых преподавателей засунуть
не мешало бы :-/). На мой взгляд, Школа - это одна из главных функций
open source, как социального явления.

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

Re: Perl or Python?

19 марта 2009 г. 18:18 пользователь Aleksey Cheusov v...@gmx.net написал:
 Но. Замечания по орфографии предпочтительнее присылать лично, если они
 не подкреплены замечаниями по теме обсуждения.

Замётано.

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

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

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

Извините.

Re: Perl or Python?

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


 А где тут дешевая пропаганда? Функциональный подход весьма хорошо
 упорядочивает мысли, у кого они есть, остальные начинают с бейсика.
   ^
Дешевую пропаганду я подчеркнул.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 15:19:58 Aleksey Cheusov wrote:
Программы на том же С++ замечательно сегфолтятся, несмотря на всю
типизацию переменных - ну объявили типизированную переменную, а вот
указатель на эту переменную может хрен знает куда указывать.

Детсад на выезде у нас тут или как?

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

Ничего, кроме скорости выполнения и упрощения
компилятора/интерпретатора типизация переменных не дает.

Наглое и подлое вранье! Разницу между compile-time и run-time проверками
знаем? А разницу в цене этих проверок?

И что эта разница дает, кроме скорости выполнения кода и упрощения его
компиляции/интерпретации? Разница в цене это и будет скорость выполнения
кода, и к надежности отношения не имеет.

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

Best regards.

Re: Perl or Python?

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

 То есть ни циклов, ничего такого, просто 3 строки, в каждой вызов
 одной функции, вложенный в другую.
Угу. Радость то какая.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

On 2009.03.19 at 16:36:52 +0200, Aleksey Cheusov wrote:

Давай всё-таки не будем игнорировать разницу между утверждениями 99%
алгоритмов -- императивные и 1% алгоритмов -- функциональные.
Пардон, между этими утверждениями я разницы не вижу :-)
[skip]
Абсолютное большинство проблемно-ориентированных языков, с которыми по
работе (Invention Machine corp.) приходится сталкиваться мне --
декларативные. Но при этом к функциональщине ни один их них не имеет
никакого отношения. А вот реализация практически всегда проще делается с

И ты по прежнему не видишь разницы?

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

Вот-вот. Правильный дизайн - это всегда top down. Чему использование
функциональной парадигмы для декомпозиции задачи крайне способствует.

делать это можно с помощью open source. Open Source - это Большая
Школа. И этим можно и нужно было бы воспользоваться, вовлекая студентов
во всякие программы типа SoC (туда и некоторых преподавателей засунуть
не мешало бы :-/). На мой взгляд, Школа - это одна из главных функций
open source, как социального явления.

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

Поэтому я бы не стал рекомендовать учиться путем чтения существующего
кода НОВИЧКУ. Это необходимый этап для intermediate и advanced.

Основа основ программирования -- это алгоритм. Функциональная же

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

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

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Sergey Spiridonov

Hello!

On Thursday 19 March 2009 14:56:23 Victor Wagner wrote:
 Например, что писать в поле цвет волос, если клиент лыс?

 Что писать в поле отпечаток указательного пальца левой руки, если
 клиенту эту левую руку оторвало в одной из прошедших войн?

 Другая часть лакун объясняется тем, что СЕЙЧАС мы этой информации не
 знаем (вроде цвета шара в момент, когда электричество отключено), но
 ПОТОМ можем узнать (повторить эксперимент).

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

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

Best regards.

Re: Perl or Python?

Привет

Владимир Ступин wrote:

 Это безсмысленно.
 
 Вы осознанно в приставке заменяете с на з? Просто уже не первый
 раз встречаю людей, которые начитались беллетристики с сайта
 www.vodaspb.ru. Там часто можно встретить такую орфографию. В
 частности, вот тут:

Возможно это украинизм? В украинском отсутствует эта бесовская ;)
приставка.
-- 
Best regards, Sergey Spiridonov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

И ты по прежнему не видишь разницы?
Разницу между чем и чем? Между императивным _кодом_ и декларативным
_описанием_? Вижу, и всегда видел.

Между двумя фразами, которые выше? Нет, не вижу, они одинаковые.
99% + 1% = 100%
Если за 100% брать именно программирование, за вычетом логического
и подобных.

Из того, что ФП этому способствует никак не следует того, что нет
средств кроме ФП, которые этому также способствуют.

Поэтому я бы не стал рекомендовать учиться путем чтения существующего
кода НОВИЧКУ. Это необходимый этап для intermediate и advanced.
Вот для этого нужен преподаватель, практикующий программирование,
с большим опытом _практической_ работы и должным уровнем кругозора.
Почти фантастика.

Вот с этим утверждением - не соглашусь. Алгоритмы - это крайне узкий
частный случай программирования. Для большинства real world задач
сформулировать алгоритм непросто, да и не нужно.
Если алгоритма нет, нет и разумного применения ФП.
Там месиво сделать не получится.

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 15:25:47 Artem Chuprina wrote:
 У Вас либо бывает такое в жизни (и тогда Вы, гм, можете у специалиста в
 предметной области выяснить, что это значит), либо не бывает, и тогда Вы
 пишете констрейнт not null.  А так, чтобы что значит цвет шара не
 определен, но записи с NULL в базе, тем не менее, есть - это ошибка в
 программе.  И от того, что в качестве NULL используется пустая строка,
 суть ошибки не меняется.

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

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

Best regards.

Re: Perl or Python?

On 2009.03.19 at 18:07:47 +0300, Alexey Pechnikov wrote:

Hello!

On Thursday 19 March 2009 14:56:23 Victor Wagner wrote:
Например, что писать в поле цвет волос, если клиент лыс?

Что писать в поле отпечаток указательного пальца левой руки, если
клиенту эту левую руку оторвало в одной из прошедших войн?

Другая часть лакун объясняется тем, что СЕЙЧАС мы этой информации не
знаем (вроде цвета шара в момент, когда электричество отключено), но
ПОТОМ можем узнать (повторить эксперимент).

Когда нет информации, то ничего и не пишем. Если же нас вдруг может

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

заинтересовать причина отсутствия информации, то пишем сообщение об ошибке.

Речь идет о базе данных. Которая должна обрабатываться машиной.
Алгоритм рассчета прогноза погоды НЕ УМЕЕТ интерпретировать сообщения об
ошибке. Как максимум он может исключить из рассчета либо данную точку
вообще, либо только данный параметр.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

On 2009.03.19 at 17:12:53 +0200, Aleksey Cheusov wrote:

Если за 100% брать именно программирование, за вычетом логического
и подобных.

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

Нет других средств, которые были бы столь же снабжены хорошей
литературой.

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

Поэтому начинать ему придется с чтения книжек и деланья упражнений.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 15:36:50 Artem Chuprina wrote:
 В результате в реальной жизни мы пишем NULL в поле сломавшегося датчика,
 и... правильно, логика работы с NULL разработана так, что в подавляющем
 большинстве случаев она работает правильно: если обсчету нужно значение
 с этого датчика, то записи, где он сломан, в обсчет не попадают.

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

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

Best regards.

Re: nfs

2009-03-19 Пенетрантность Andrei Lomov

chaos wrote:

 aptitude remove fam :)
 а живёт он в /etc/init.d/fam :)

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

-- 
Всего доброго,
А.Л.



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 18:17:03 Victor Wagner wrote:
Другая часть лакун объясняется тем, что СЕЙЧАС мы этой информации не
знаем (вроде цвета шара в момент, когда электричество отключено), но
ПОТОМ можем узнать (повторить эксперимент).

Когда нет информации, то ничего и не пишем. Если же нас вдруг может

заинтересовать причина отсутствия информации, то пишем сообщение об
ошибке.

Беда в том, что NULL это может быть и отсутствие информации, и ее
некорректность, и даже невалидность самого вопроса. Например, при
использовании NULL в базу может быть вставлена дата 31 февраля:

create table tests(date,value);
insert into tests (date,value) values ('2009-02-31',NULL);

Ну и что мы получаем:

select count(value) from tests;
0
select count(*) from tests;
1

Итак, сколько у вас измерений проведено? А черт его знает. Может, это ошибка в
дате и есть 1 измерение, сделанное непонятно когда. А может, это сделано
специально и сутки 29, 30 и 31-го февраля авторами программы полагаются
нулевой длительности для упрощения каких-то расчетов. Или использован другой
календарь. В итоге эту БД можно выкинуть на помойку - вы даже не можете
определить, корректные ли в ней данные и что они значат и сколько их вообще.
Вот вам результат использования NULL.

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

Best regards.

Re: Perl or Python?

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

А теперь признаете, что ни хрена она не помогает и нетипизированный
тикль надежнее типизированного С++.
Во-первых, я этого не говорил. Во-вторых, такое, конечно же, вполне
возможно, и теоретически и практически. В-третьих, я постоянно вижу
падения программ на руби с сообщениями типа undefined value...nil
траляля. Это лучше segfault-а только в том, что это безопасно в плане
vulnerabilities. В-четвертых, у моих знакомых есть ОЧЕНЬ отрицательный
опыт написания БОЛЬШОЙ программы на тикле (у меня такого опыта нет). Не
то, чтобы это аргумент, но success story я бы это не назвал.

Оказывается, чтобы создавать надежные программы, нужны динамические
языки, и неважно, типизированы они или нет.
Нет, не оказывается. Полно крупных надежных программ, написанных на
java, C#, Ada, и прочих, которые динамическими не являются. Надежные
программы можно создать на любом языке, и на динамическом и на
статическом, вопрос только в цене.

Ничего, кроме скорости выполнения и упрощения
компилятора/интерпретатора типизация переменных не дает.

Наглое и подлое вранье! Разницу между compile-time и run-time проверками
знаем? А разницу в цене этих проверок?

И что эта разница дает, кроме скорости выполнения кода и упрощения его
компиляции/интерпретации?
Из статической типизации не следует компилируемость языка, то есть
длительной _предварительной_ компиляции. И наоборот. Из
компилируемости языка не следует то, что он со статической
типизацией. Lua, например умеет компилироваться в исполняемый шитый код
(бинарь), но он динамический. Еще пример, для С, ЯП со статической
типизацией, существуют интерпретаторы.

Разница в цене это и будет скорость выполнения кода,
Это не имеет никакого отношения к обсуждаемой теме. Слово компилятор
само по себе не означает быстрый. Слово интерпретатор само по себе
не означает медленный. Точно так же динамическая типизация не всегда
в результате дает медленно исполняемый код. В некоторых случаях
транслятор вполне способен выяснить значение какого типа ожидается в
данной конкретной функции, и сгенерировать соответствующий код
максимально эффективно. Многие трансляторы Лиспа, например, так делают.

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

да еще и пишете, простите меня, безграмотно.
Да. Именно такими аргументами и отличается срач, как тут было сказано,
от дискуссии.

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
18:15:35 +0300:

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

AP Вы же предлагаете _отказаться_ от всех сообщений об ошибках,

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

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

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Чем отличается свобода от независимости?
Независимость - это когда за тебя не платят.
А свобода - когда за тебя не думают.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Между утверждением 1% функциональный и утверждением 99% императивный.
Потому что не все, что неимперативное - функциональное (что не мешает
всему этому неимперативному быть именно КОДОМ, который непосредтсвенно
интерпретируется машиной)
Слово непосредственно я бы убрал. Во многих DSL-ях нифига оно не
непосредственно выполняется.
Смотри хоть те же regexp-ы и finite state transducers.
Последние - более, чем вычисления, даже наглядно,
на вход подаешь одно, а выходе... Ух ты!!!
То есть вполне себе программирование.

Если за 100% брать именно программирование, за вычетом логического
и подобных.

Смешно :-)

Поэтому начинать ему придется с чтения книжек и деланья упражнений.
Пусть подойдет в ближайший к нему университет и попросит совета.
Литературы ему навалят вагон. Если это будет хороший университет,
навалят хорошей литературы, я уверен. А если подойти в 10 разных мест и
сделать выборку литературы по частоте и авторитетности места, вряд ли в
список попадет Язык XXX за 21 день. Еще можно взять литературу,
рекомендуемую ближайшим ВАК-ом. Но все это, конечно, для профессиональной
деятельности.

--
Best regards, Aleksey Cheusov.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 18:38:17 Aleksey Cheusov wrote:
Оказывается, чтобы создавать надежные программы, нужны динамические
языки, и неважно, типизированы они или нет.

Нет, не оказывается. Полно крупных надежных программ, написанных на
java, C#, Ada, и прочих, которые динамическими не являются. Надежные
программы можно создать на любом языке, и на динамическом и на
статическом, вопрос только в цене.

В таком случае мы приходим к вопросу о квалификации программиста в выбранном
им языке. Но от языка программирования этот фактор вообще никак не зависит...

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

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

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

и к надежности отношения не имеет.

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

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

да еще и пишете, простите меня, безграмотно.

Да. Именно такими аргументами и отличается срач, как тут было сказано,
от дискуссии.

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

Best regards.

Re: Perl or Python?

Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
18:38:10 +0300:

AP Беда в том, что NULL это может быть и отсутствие информации, и ее
AP некорректность, и даже невалидность самого вопроса. Например, при
AP использовании NULL в базу может быть вставлена дата 31 февраля:

AP create table tests(date,value);
AP insert into tests (date,value) values ('2009-02-31',NULL);

AP Ну и что мы получаем:

AP select count(value) from tests;
AP 0
AP select count(*) from tests;
AP 1

AP Итак, сколько у вас измерений проведено? А черт его знает. Может,
AP это ошибка в дате и есть 1 измерение, сделанное непонятно когда. А
AP может, это сделано специально и сутки 29, 30 и 31-го февраля
AP авторами программы полагаются нулевой длительности для упрощения
AP каких-то расчетов. Или использован другой календарь. В итоге эту БД
AP можно выкинуть на помойку - вы даже не можете определить,
AP корректные ли в ней данные и что они значат и сколько их вообще.
AP Вот вам результат использования NULL.

Что-то ты уже ахинею какую-то несешь... Начинал вроде небессмысленно...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Если руки растут из @#$#, то это ноги

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 18:49:51 Artem Chuprina wrote:
 Так, а вот приписывать мне своих тараканов не надо.  Это Вы как раз
 предлагаете либо не писать в базу данные вообще (что неприемлемо, яркий
 пример приводил Витус), либо писать туда нечто, не являющееся данными
 (т.е. делать таблицу непригодной для обработки).

А вы утверждаете, что использование констрэйнта NOT NULL _ухудшает_ качество 
БД?

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

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

И это мы еще не говорим о том, что в SQL вообще некорректно NULL значения 
обрабатываются, но об этом Дейт уже четверть века говорит.

Best regards.

Re: Perl or Python?

Aleksey Cheusov - Debian-Russian2 @ Thu, 19 Mar 2009 17:38:17 +0200:

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

Так а не бывает прочих равных. Строгая типизация не бесплатна не
только для разработчика компилятора, но и для программиста. Особенно -
когда таки надо работать с коллекцией разнотипных данных...

AC vulnerabilities. В-четвертых, у моих знакомых есть ОЧЕНЬ
AC отрицательный опыт написания БОЛЬШОЙ программы на тикле (у меня
AC такого опыта нет). Не то, чтобы это аргумент, но success story я бы
AC это не назвал.

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

Оказывается, чтобы создавать надежные программы, нужны динамические
языки, и неважно, типизированы они или нет.
AC Нет, не оказывается. Полно крупных надежных программ, написанных на
AC java, C#, Ada, и прочих, которые динамическими не являются.
AC Надежные программы можно создать на любом языке, и на динамическом
AC и на статическом, вопрос только в цене.

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

Ничего, кроме скорости выполнения и упрощения
компилятора/интерпретатора типизация переменных не дает.

Наглое и подлое вранье! Разницу между compile-time и run-time проверками
знаем? А разницу в цене этих проверок?

И что эта разница дает, кроме скорости выполнения кода и упрощения его
компиляции/интерпретации?
AC Из статической типизации не следует компилируемость языка, то есть
AC длительной _предварительной_ компиляции. И наоборот. Из
AC компилируемости языка не следует то, что он со статической
AC типизацией. Lua, например умеет компилироваться в исполняемый шитый код
AC (бинарь), но он динамический. Еще пример, для С, ЯП со статической
AC типизацией, существуют интерпретаторы.

Статическая типизация интересна только на стадии компиляции. Если код
интерпретируется, статическая типизация становится эквивалентна
динамической :-)

Хотя, конечно, JIT-компиляция разницу все же дает.

Другое дело, что я вообще не очень понимаю смысл контроля _типов_ иначе
как в качестве контроля значений для бедных. Для решения задачи нужно
контролировать _значения_. А отдельный контроль _типа_ имеет смысл
только тогда, когда динамический контроль значения (вместе с типом) -
слишком дорогое удовольствие. Т.е. там, где я пишу на C и подумываю об
ассемблере - там да, имеет смысл. Там я ради ускорения выполнения иду
на отсутствие контроля в рантайме. Там данные будут интерпретироваться
так, как я сказал. И вот чтобы хоть как-то отследить мои ошибки, я
прошу компилятор проконтролировать хотя бы объявленные типы.

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

и к надежности отношения не имеет.
AC Имеет. Динамические языки требуют на порядок большего количества
AC тестов. Это и есть цена динамичности.

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

AC То, что многие опенсорсники их не пишут, полагаяюсь исключительно
AC на бетатестирование - это их проблемы.

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

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 18:55:14 Artem Chuprina wrote:
Что-то ты уже ахинею какую-то несешь... Начинал вроде небессмысленно...

Мы не можем определить, что означает NULL в поле. Витус ловко миновал
следующий момент: для него выглядит логичным вставить в даные измерений NULL,
когда термометр медведь унес, но при обработке собранных данных возникнут
проблемы. В частности: следует ли платить Витусу за измерение температуры в
этот день, если неизвестно, то ли он весь день читал Лукьяненко и забыл
смерить температуру, то ли температуру мерять ходил, но в силу объективных
причин данных не получил. БД может использоваться для решения разных задач,
так понятнее?

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

Best regards.

Re: Perl or Python?


Twas brillig at 19:15:17 19.03.2009 UTC+03 when r...@ran.pp.ru did gyre and 
gimble:

 AC Особенно - когда таки надо работать с коллекцией разнотипных
 AC данных...

data MyItem = Something Int | Other String String | YouKnow (IO String)
typename MyCollection = [MyItem]

-- 


pgpIxJN2PJr2i.pgp
Description: PGP signature

Re: Perl or Python?

Hello!

On Thursday 19 March 2009 19:15:17 Artem Chuprina wrote:
  AC vulnerabilities. В-четвертых, у моих знакомых есть ОЧЕНЬ
  AC отрицательный опыт написания БОЛЬШОЙ программы на тикле (у меня
  AC такого опыта нет). Не то, чтобы это аргумент, но success story я бы
  AC это не назвал.

 Ну а у Печникова, вон, есть очень положительный.

Не только у меня. Данилов тоже с успехом тикль использует. Не говоря уже о 
тикле в цисках и еще очень много где.

Best regards.

Re: Perl or Python?


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

 Нет, не оказывается. Полно крупных надежных программ, написанных на
 java, C#, Ada, и прочих, которые динамическими не являются.  Надежные
 программы можно создать на любом языке, и на динамическом и на
 статическом, вопрос только в цене.

 В таком случае мы приходим к вопросу о квалификации программиста в выбранном 
 им языке.
Я же сказал при прочих равных.

 Но от языка программирования этот фактор вообще никак не зависит...

Зависит. И очень сильно. Плюсы и минусы ЯП со статической и динамической
типизацией расписаны в букварях. И их нужно читать. Желательно до того,
как рассуждать об этом.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

On 2009.03.19 at 18:38:10 +0300, Alexey Pechnikov wrote:

 
 Беда в том, что NULL это может быть и отсутствие информации, и ее 
 некорректность, и даже невалидность самого вопроса. Например, при 
 использовании NULL в базу может быть вставлена дата 31 февраля:
 
 create table tests(date,value);
 insert into tests (date,value) values ('2009-02-31',NULL);
 Ну и что мы получаем:
 
 select count(value) from tests;
 0
 select count(*) from tests;
 1

Это где такие базы данных берут?

$psql template1
Welcome to psql 8.3.0, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
   \h for help with SQL commands
   \? for help with psql commands
   \g or terminate with semicolon to execute query
   \q to quit

template1=# create table tests (date timestamp, value varchar);
CREATE TABLE

template1=# insert into tests values ('2009-02-31','foo');
ERROR:  значение поля типа date/time вне диапазона: 2009-02-31
template1=# insert into tests values ('2009-02-31',NULL);
ERROR:  значение поля типа date/time вне диапазона: 2009-02-31

И как-то глубоко ему пофиг NULL или не NULL в соседней колонке. 
Нельзя некорректную дату вставить.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?


Twas brillig at 19:46:45 19.03.2009 UTC+03 when vi...@wagner.pp.ru did gyre and 
gimble:

 VW Это где такие базы данных берут?

[разглядывая одно поделие] А некоторые СУБД ещё и значения, не
подходящие под ENUM, тихо в пустую строку превращают.

-- 


pgpfttgZ5Z2ja.pgp
Description: PGP signature

Re: Perl or Python?

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

Так а не бывает прочих равных. Строгая типизация не бесплатна не
только для разработчика компилятора, но и для программиста.
Строгая типизация, даже частичная, как в Pike-е - это подарок и для
транслятора и для программиста. Транслятору меньше работы по выводу
типа из контекста и меньше работы по хитрой оптимизации, типа той, что
делает Lisp. Программисту - больше проверок вылавливается
compile-time. Это опять же азбука.
Многа букафф в слове string, набрать ниасилил - не аргумент.

AC Из статической типизации не следует компилируемость языка, то есть
AC длительной _предварительной_ компиляции. И наоборот. Из
AC компилируемости языка не следует то, что он со статической
AC типизацией. Lua, например умеет компилироваться в исполняемый шитый код
AC (бинарь), но он динамический. Еще пример, для С, ЯП со статической
AC типизацией, существуют интерпретаторы.

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

Хотя, конечно, JIT-компиляция разницу все же дает.
JIT - это очень дорогая технология, придуманная для того, чтобы не
работать над эффективным внутренним представлением (шитым кодом) :-)
Часть пиара ;-)

Другое дело, что я вообще не очень понимаю смысл контроля _типов_ иначе
как в качестве контроля значений для бедных. Для решения задачи нужно
контролировать _значения_. А отдельный контроль _типа_ имеет смысл
только тогда, когда динамический контроль значения (вместе с типом) -
слишком дорогое удовольствие.
И тебе тот же ответ, run-time проверки очень дороги по сравнению с
compile-time для любых более-менее крупных программ. По-моему это
очевидно. А в словах int|string|float|map|set|function|object|mixed
по-моему не так много букв, чтобы было лень их набрать.
Про подарки смотри выше.

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

AC Имеет. Динамические языки требуют на порядок большего количества
AC тестов. Это и есть цена динамичности.

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

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

AC То, что многие опенсорсники их не пишут, полагаяюсь исключительно
AC на бетатестирование - это их проблемы.

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

Угу, в проектах уровня hello world. И это, технологии формального
доказательства правильности программ вполне развиты и для императивного
подхода тоже. Наука программирования Д.Грис, самая популярная по-моему
книга этого жанра.

--
Best regards, Aleksey Cheusov.
In-Reply-To: cht8q-6k...@gated-at.bofh.it (Artem Chuprina's message of Thu,
19 Mar 2009 17:20:07 +0100)
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Perl or Python?

2009-03-19 Пенетрантность Sergei Stolyarov

Hello!

On Thursday 19 March 2009 19:58:59 Aleksey Cheusov wrote:
  Другое дело, что я вообще не очень понимаю смысл контроля _типов_ иначе
  как в качестве контроля значений для бедных.  Для решения задачи нужно
  контролировать _значения_.  А отдельный контроль _типа_ имеет смысл
  только тогда, когда динамический контроль значения (вместе с типом) -
  слишком дорогое удовольствие.

 И тебе тот же ответ, run-time проверки очень дороги по сравнению с
 compile-time для любых более-менее крупных программ.  По-моему это
 очевидно. А в словах int|string|float|map|set|function|object|mixed
 по-моему не так много букв, чтобы было лень их набрать.

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

Best regards.

Xorg 1.6 и обновление параметров без перезагрузки

Здравствуйте.

На ноутбуке установлен xorg-server 1.6 (experimental). Допустим, я поменял 
параметры девайса в соответствующем fdi-файле, перезагрузил hal. Как теперь 
заставить xorg перечитать эти параметры, не перезагружая их? Конкретно имеется 
в виду synaptics touchpad.

-- 
Best regards
Sergei Stolyarov

Re: Perl or Python?