subject:"Несколько вопросов вразброс"

2012-07-21 Пенетрантность Stanislav Maslovski

On 21.07.2012 09:31, Igor Chumak wrote:
 Ага. И противопульного бронирования там тоже нет ;)
Вот это зря... ;-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500a6768.6050...@yandex.ru

Re: Несколько вопросов вразброс

On Fri, Jul 20, 2012 at 09:28:28PM +0400, Артём Н. wrote:
 On 20.07.2012 10:54, Stanislav Maslovski wrote:
  On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:
  Защиту от запуска второй копии я делал так:
 
  if [ -f $lockfile ]
  then
   echo Lock file $0.lock exist!
  while [ -f $lockfile ]
   do
 pid=`cat $lockfile`
 if [ -n $pid ]; then
  
  Скрипт мог умереть, не потерев за собой свой lockfile, а его PID - мог
  быть занят новым процессом (каким-нибудь рефоркающимся демоном, например).
  В результате - deadlock.
 Кстати, точно... Надо тогда проверять процесс по имени файла. Хотя, не факт, 
 что
 имя не могло измениться (переименовали программку просто - и всё). По идее,
 остаётся только мьютекс. Ну или тот же flock.
 
  echo pid=$pid in lockfile; our pid=$$
  if ps $pid ; then
  echo Process exist; waiting
  else
  echo no process with $pid; remove lockfile
  rm -f $lockfile
  fi
  else
  echo no process with $pid; remove lockfile
  rm -f $lockfile
 fi
 echo sleep 10s; sleep 10
   done
  fi
  Ну и тут, строго говоря, имеет место быть race condition.
 В упор не вижу. Где?

А вот как раз перед строчкой, которую ты удалил.

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

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120721141845.GA18525@kaiba.homelan

Re: Несколько вопросов вразброс

On 21.07.2012 18:18, Stanislav Maslovski wrote:
 Ну и тут, строго говоря, имеет место быть race condition.
 В упор не вижу. Где?
 А вот как раз перед строчкой, которую ты удалил.
 То есть, там классический race между проверкой семафора и его
 установкой, поскольку делается это двумя *отдельными* операциями,
 а должно делаться *атомарно*.

   pid=`cat $lockfile`
   if [ -n $pid ]; then
echo pid=$pid in lockfile; our pid=$$
if ps $pid ; then
echo Process exist; waiting
else
.
 done
fi
echo $$$lockfile


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

Блин. Я недоглядел.
И как с этим бороться (кроме как flock)?

А блокировка в flock выполняется атомарно?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500abe25.3060...@yandex.ru

Re: Несколько вопросов вразброс

On 21.07.2012 18:18, Stanislav Maslovski wrote:
 То есть, там классический race между проверкой семафора и его
 установкой, поскольку делается это двумя *отдельными* операциями,
 а должно делаться *атомарно*.
Так получается, что и здесь такая же фигня?

   [ -r $OPT_FBACKUPSTATUS_FILE ] || { dbg 2 Backup system not
initialized...; return 0; }
   [ x$(cat $OPT_FBACKUPSTATUS_FILE) != x$BS_READY ]  { dbg 2 Backup
system not ready for backup processing...; return 0; }

   notify Backup started...
   echo $$  $BACKUP_PID_FILE
   echo $BS_INPROCESS  $OPT_FBACKUPSTATUS_FILE


Только flock..?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500abee0.6020...@yandex.ru

Re: Несколько вопросов вразброс

Блин, в скриптах про многопоточность/многозадачность не думаешь... :-(


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500abf07.6060...@yandex.ru

Re: Несколько вопросов вразброс

'
if [ -e $LOCKFILE ]; then
echo 2 Warning: $LOCKFILE present, not running updatedb.
exit 1
else
touch $LOCKFILE
fi
'
Здесь тоже race (это /etc/cron.daily/mlocate)?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500aeba2.7070...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-21 Пенетрантность igor Chumak

В Sat, 21 Jul 2012 21:49:22 +0400
Артём Н. artio...@yandex.ru пишет:

 '
 if [ -e $LOCKFILE ]; then
 echo 2 Warning: $LOCKFILE present, not running updatedb.
 exit 1
 else
 touch $LOCKFILE
 fi
 '
 Здесь тоже race (это /etc/cron.daily/mlocate)?
 
 

Это защита от того, что скрипт, запускающийся раз в сутки, не
закончится за 24 часа. Затрудняюсь придумать условие для гонок.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120721223155.3437e1a1@ubuntu

Re: Несколько вопросов вразброс

2012-07-20 Пенетрантность Stanislav Maslovski

On 21.07.2012 23:31, igor Chumak wrote:
 В Sat, 21 Jul 2012 21:49:22 +0400
 Артём Н. artio...@yandex.ru пишет:
 
 '
 if [ -e $LOCKFILE ]; then
 echo 2 Warning: $LOCKFILE present, not running updatedb.
 exit 1
 else
 touch $LOCKFILE
 fi
 '
 Здесь тоже race (это /etc/cron.daily/mlocate)?


 
 Это защита от того, что скрипт, запускающийся раз в сутки, не
 закончится за 24 часа. Затрудняюсь придумать условие для гонок.
В теории, его могут запустить несколько раз вручную... 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500b8bdb.7080...@yandex.ru

Re: Несколько вопросов вразброс

On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:
 Защиту от запуска второй копии я делал так:
 
 if [ -f $lockfile ]
 then
  echo Lock file $0.lock exist!
 while [ -f $lockfile ]
  do
pid=`cat $lockfile`
if [ -n $pid ]; then

Скрипт мог умереть, не потерев за собой свой lockfile, а его PID - мог
быть занят новым процессом (каким-нибудь рефоркающимся демоном, например).
В результате - deadlock.

 echo pid=$pid in lockfile; our pid=$$
 if ps $pid ; then
 echo Process exist; waiting
 else
 echo no process with $pid; remove lockfile
 rm -f $lockfile
 fi
 else
 echo no process with $pid; remove lockfile
 rm -f $lockfile
fi
echo sleep 10s; sleep 10
  done
 fi

Ну и тут, строго говоря, имеет место быть race condition.

 echo $$$lockfile
 
 (Если обнаруживаем вторую копию - ждем пока она завершится.)

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120720065444.GA9249@kaiba.homelan

Re: Несколько вопросов вразброс

2012-07-20 Пенетрантность Stanislav Maslovski

On Thu, Jul 19, 2012 at 04:24:05PM +0300, Igor Chumak wrote:
 19.07.2012 13:20, Dmitry Nezhevenko пишет:
 On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:
 -куть
 ахренеть... Если уже хочется оберток на шелле, то есть flock
 
 Еще одним велосипедом в природе стало больше. Буду знать ;).

Хм. Велосипедом скорее является твой скрипт ;)

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120720065717.GB9249@kaiba.homelan

Re: Несколько вопросов вразброс

2012-07-20 Пенетрантность Stanislav Maslovski

On Thu, Jul 19, 2012 at 01:08:59PM +0300, Andrey Tataranovich wrote:
 Такая защита может наплодить процессов, которые месяцами ждут разблокировки.
 
 Для себя я выбрал решение с таймаутом, если скажем за 6 часов блокировку не
 удалось получить, то процесс вываливается с ошибкой.

На всякий случай: этот функционал есть у утилиты lockfile из пакета
procmail.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120720071005.GA11130@kaiba.homelan

Re: Несколько вопросов вразброс

2012-07-20 Пенетрантность Иван Лох

On Fri, Jul 20, 2012 at 11:10:05AM +0400, Stanislav Maslovski wrote:
 On Thu, Jul 19, 2012 at 01:08:59PM +0300, Andrey Tataranovich wrote:
  Такая защита может наплодить процессов, которые месяцами ждут разблокировки.
  
  Для себя я выбрал решение с таймаутом, если скажем за 6 часов блокировку не
  удалось получить, то процесс вываливается с ошибкой.
 
 На всякий случай: этот функционал есть у утилиты lockfile из пакета
 procmail.

Еще есть пакет lockfile-progs

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120720120008.ga17...@nano.ioffe.rssi.ru

Re: Несколько вопросов вразброс

2012-07-20 Пенетрантность Igor Chumak


20.07.2012 09:57, Stanislav Maslovski пишет:

On Thu, Jul 19, 2012 at 04:24:05PM +0300, Igor Chumak wrote:

19.07.2012 13:20, Dmitry Nezhevenko пишет:

On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:

-куть

ахренеть... Если уже хочется оберток на шелле, то есть flock


Еще одним велосипедом в природе стало больше. Буду знать ;).

Хм. Велосипедом скорее является твой скрипт ;)


Дык я ж и не спорю ;)
Просто написать 10 строчек оказалось быстрее, чем выгуглировать 
существование flock и прочих специализированных вещей.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50096bf5.4060...@gmail.com

Re: Несколько вопросов вразброс

2012-07-20 Пенетрантность Артём Н.

On 20.07.2012 10:54, Stanislav Maslovski wrote:
 On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:
 Защиту от запуска второй копии я делал так:

 if [ -f $lockfile ]
 then
  echo Lock file $0.lock exist!
 while [ -f $lockfile ]
  do
pid=`cat $lockfile`
if [ -n $pid ]; then
 
 Скрипт мог умереть, не потерев за собой свой lockfile, а его PID - мог
 быть занят новым процессом (каким-нибудь рефоркающимся демоном, например).
 В результате - deadlock.
Кстати, точно... Надо тогда проверять процесс по имени файла. Хотя, не факт, что
имя не могло измениться (переименовали программку просто - и всё). По идее,
остаётся только мьютекс. Ну или тот же flock.

 echo pid=$pid in lockfile; our pid=$$
 if ps $pid ; then
 echo Process exist; waiting
 else
 echo no process with $pid; remove lockfile
 rm -f $lockfile
 fi
 else
 echo no process with $pid; remove lockfile
 rm -f $lockfile
fi
echo sleep 10s; sleep 10
  done
 fi
 Ну и тут, строго говоря, имеет место быть race condition.
В упор не вижу. Где?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5009953c.2060...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-20 Пенетрантность Dmitry Nezhevenko

On Fri, Jul 20, 2012 at 05:32:21PM +0300, Igor Chumak wrote:
 Просто написать 10 строчек оказалось быстрее, чем выгуглировать
 существование flock и прочих специализированных вещей.

Ну начать можно с того, что у твоего велосипеда куча race conditions...
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

2012-07-20 Пенетрантность Igor Chumak

20.07.2012 22:37 пользователь Dmitry Nezhevenko d...@inhex.net написал:

 On Fri, Jul 20, 2012 at 05:32:21PM +0300, Igor Chumak wrote:
  Просто написать 10 строчек оказалось быстрее, чем выгуглировать
  существование flock и прочих специализированных вещей.

 Ну начать можно с того, что у твоего велосипеда куча race conditions...

 --
 WBR, Dmitry

Ага. И противопульного бронирования там тоже нет ;)
Постановка задачи следующая: скрипт запускается по крону 2 раза в день, но
может запускаться и вручную. Одновременно может работать только 1 копия, но
однажды запущенный скрипт должен доработать до конца. За год сбоев не было
;)

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Igor Chumak

18.07.2012 17:46, Артём Н. пишет:

On 18.07.2012 14:05, Igor Chumak wrote:

17.07.2012 18:34, Артём Н. пишет:

On 17.07.2012 11:24, Artem Chuprina wrote:

Артём Н. - debian-russian@lists.debian.org @ Thu, 12 Jul 2012 20:31:32
+0400:

Тогда вопрос: почему? Комментарии есть. Код оформлен, как мне кажется, в
читаемом стиле. Трюков не применялось. Из-за чего?

Дык 500 строк кода.. Если код в экран не влазит, и одним взглядом его не окинешь
- значит это уже не совет, а платный суппорт ;)
А так , не спорю, код написан, код оформлен, код , возможно , работает ;)

Не работал. ;-) Я забыл аргументы main передать и были некоторые косяки. В том,
что не протестировано. Сейчас исправил. Теперь он успешно делает бэкапы. Даже
первый полный бэкап того, что хотел вчера сделал.
Но ещё минус: сейчас есть блокировка от запуска второй копии с тем же конфигом,
но сигналы не ловлю. Поэтому, при нажатии Ctrl+C он завершается не убирая
блокировку. В принципе-то не очень важно, потому что запускаться будет по
anacron, но потом доделаю.

Защиту от запуска второй копии я делал так:

if [ -f $lockfile ]
then
echo Lock file $0.lock exist!
while [ -f $lockfile ]
do
pid=`cat $lockfile`
if [ -n $pid ]; then
echo pid=$pid in lockfile; our pid=$$
if ps $pid ; then
echo Process exist; waiting
else
echo no process with $pid; remove lockfile
rm -f $lockfile
fi
else
echo no process with $pid; remove lockfile
rm -f $lockfile
fi
echo sleep 10s; sleep 10
done
fi
echo $$$lockfile

(Если обнаруживаем вторую копию - ждем пока она завершится.)

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5007bce7.70...@gmail.com

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Andrey Tataranovich

10:53 Thu 19 Jul, Igor Chumak wrote:
 Защиту от запуска второй копии я делал так:
 
 if [ -f $lockfile ]
 then
  echo Lock file $0.lock exist!
 while [ -f $lockfile ]
  do
pid=`cat $lockfile`
if [ -n $pid ]; then
 echo pid=$pid in lockfile; our pid=$$
 if ps $pid ; then
 echo Process exist; waiting
 else
 echo no process with $pid; remove lockfile
 rm -f $lockfile
 fi
 else
 echo no process with $pid; remove lockfile
 rm -f $lockfile
fi
echo sleep 10s; sleep 10
  done
 fi
 echo $$$lockfile
 
 (Если обнаруживаем вторую копию - ждем пока она завершится.)

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

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

-- 
WBR, Andrey Tataranovich


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719100859.gb26...@debbox.it

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Dmitry Nezhevenko

On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:
 Защиту от запуска второй копии я делал так:
 
 if [ -f $lockfile ]
 then
  echo Lock file $0.lock exist!
 while [ -f $lockfile ]
  do
pid=`cat $lockfile`
if [ -n $pid ]; then
 echo pid=$pid in lockfile; our pid=$$
 if ps $pid ; then
 echo Process exist; waiting
 else
 echo no process with $pid; remove lockfile
 rm -f $lockfile
 fi
 else
 echo no process with $pid; remove lockfile
 rm -f $lockfile
fi
echo sleep 10s; sleep 10
  done
 fi
 echo $$$lockfile

ахренеть... Если уже хочется оберток на шелле, то есть flock
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Igor Chumak


19.07.2012 13:20, Dmitry Nezhevenko пишет:

On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:

-куть

ахренеть... Если уже хочется оберток на шелле, то есть flock


Еще одним велосипедом в природе стало больше. Буду знать ;).


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50080a75.7000...@gmail.com

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Dmitry Nezhevenko

On Thu, Jul 19, 2012 at 04:24:05PM +0300, Igor Chumak wrote:
 19.07.2012 13:20, Dmitry Nezhevenko пишет:
 On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:
 -куть
 ахренеть... Если уже хочется оберток на шелле, то есть flock
 
 Еще одним велосипедом в природе стало больше. Буду знать ;).

У тебя есть предложение как это сделать на шелле удобнее этого?

   (
 flock -n 9 || exit 1
 # ... commands executed under lock ...
   ) 9/var/lock/mylockfile

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Igor Chumak


19.07.2012 16:33, Dmitry Nezhevenko пишет:

On Thu, Jul 19, 2012 at 04:24:05PM +0300, Igor Chumak wrote:

19.07.2012 13:20, Dmitry Nezhevenko пишет:

On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:

-куть

ахренеть... Если уже хочется оберток на шелле, то есть flock


Еще одним велосипедом в природе стало больше. Буду знать ;).

У тебя есть предложение как это сделать на шелле удобнее этого?

(
  flock -n 9 || exit 1
  # ... commands executed under lock ...
) 9/var/lock/mylockfile


Билин.. Ох уж эти борцы за мировую гармонию.. ;)

flock красивше выглядит, кто ж спорит, но велосипед уже написан и ездит.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50080df5.3030...@gmail.com

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Артём Н.

On 19.07.2012 11:53, Igor Chumak wrote:
echo sleep 10s; sleep 10
  done
 fi
 echo $$$lockfile
 (Если обнаруживаем вторую копию - ждем пока она завершится.)
Похоже. Но я не жду, а просто вываливаюсь, ибо мне не требуется работать, если
работает другая копия:
[ -r $OPT_FBACKUPSTATUS_FILE ] || { dbg 2 Backup system not initialized...;
return 0; }
[ x$(cat $OPT_FBACKUPSTATUS_FILE) != x$BS_READY ]  { dbg 2 Backup system
not ready for backup processing...; return 0; }


Где OPT_FBACKUPSTATUS_FILE хранит флаг, указывающий в каком состоянии система.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50081a12.7010...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Артём Н.

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50081a80.6070...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-19 Пенетрантность Артём Н.

On 19.07.2012 17:33, Dmitry Nezhevenko wrote:
 On Thu, Jul 19, 2012 at 04:24:05PM +0300, Igor Chumak wrote:
 19.07.2012 13:20, Dmitry Nezhevenko пишет:
 On Thu, Jul 19, 2012 at 10:53:11AM +0300, Igor Chumak wrote:
 -куть
 ахренеть... Если уже хочется оберток на шелле, то есть flock

 Еще одним велосипедом в природе стало больше. Буду знать ;).
 
 У тебя есть предложение как это сделать на шелле удобнее этого?
 
(
  flock -n 9 || exit 1
  # ... commands executed under lock ...
) 9/var/lock/mylockfile
 
Про flock не знал. Спасибо. Пригодится. :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50081cfc.7030...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-18 Пенетрантность Igor Chumak


17.07.2012 18:34, Артём Н. пишет:

On 17.07.2012 11:24, Artem Chuprina wrote:

Артём Н. -  debian-russian@lists.debian.org  @ Thu, 12 Jul 2012 20:31:32 +0400:

Дык, кто же будет это читать... Нужна мотивация.
  АН  Вы прям убили мою светлую идею на корню. :-D
  АН  Я понимаю, что читать и разбирать по строчке нафиг никому не нужно.
  АН  Общее впечатление: читабельно, нечитабельно,
Вон там первая строчка квотинга дает ответ на этот вопрос.  Нечитабельно.

Тогда вопрос: почему? Комментарии есть. Код оформлен, как мне кажется, в
читаемом стиле. Трюков не применялось. Из-за чего?


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


А так , не спорю, код написан, код оформлен, код , возможно , работает ;)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50068a7e.40...@gmail.com

Re: Несколько вопросов вразброс

2012-07-18 Пенетрантность Артём Н.

On 18.07.2012 14:05, Igor Chumak wrote:
17.07.2012 18:34, Артём Н. пишет:
On 17.07.2012 11:24, Artem Chuprina wrote:
Артём Н. - debian-russian@lists.debian.org @ Thu, 12 Jul 2012 20:31:32
+0400:

Дык, кто же будет это читать... Нужна мотивация.
АН Вы прям убили мою светлую идею на корню. :-D
АН Я понимаю, что читать и разбирать по строчке нафиг никому не нужно.
АН Общее впечатление: читабельно, нечитабельно,
Вон там первая строчка квотинга дает ответ на этот вопрос. Нечитабельно.
Тогда вопрос: почему? Комментарии есть. Код оформлен, как мне кажется, в
читаемом стиле. Трюков не применялось. Из-за чего?
Дык 500 строк кода.. Если код в экран не влазит, и одним взглядом его не
окинешь
- значит это уже не совет, а платный суппорт ;)
А так , не спорю, код написан, код оформлен, код , возможно , работает ;)
Не работал. ;-) Я забыл аргументы main передать и были некоторые косяки. В том,
что не протестировано. Сейчас исправил. Теперь он успешно делает бэкапы. Даже
первый полный бэкап того, что хотел вчера сделал.
Но ещё минус: сейчас есть блокировка от запуска второй копии с тем же конфигом,
но сигналы не ловлю. Поэтому, при нажатии Ctrl+C он завершается не убирая
блокировку. В принципе-то не очень важно, потому что запускаться будет по
anacron, но потом доделаю.
Всего, кстати, получилось около 800 строк вместе с конфигами и инициализатором.
Из 500 строк mkbackup 200 строк занимают тесты.
Инициализатор просто запускает fusecompress и генерирует общий список для
rdiff-backup (список для незашифрованных каталогов хранится в /etc, а список для
шифрованного /home хранится в /home) в /tmp (у меня /tmp в памяти, так что, это
нормально - генерировать его при каждой перезагрузке, но, в идеале, конечно,
нужно пересоздавать только при изменении списков).
Конфиги разделены: общий, для инициализатора и для оболочки.

В общем-то интересует, что плохо? И читабельно ли с тестами? И читабельно ли без
тестов?

Re: Несколько вопросов вразброс

2012-07-18 Пенетрантность Артём Н.

On 18.07.2012 00:49, Иван Лох wrote:
 On Tue, Jul 17, 2012 at 07:19:17PM +0400, Артём Н. wrote:
 On 17.07.2012 00:00, Artem Chuprina wrote:
 государства ровно в той же мере.
 М... Тогда откуда берутся те 30% именно на микроядерной архитектуре?
 Как минимум, надо парсить бесчисленные сообщения. 
В плане того, что ядро - наиболее нагруженное место? И в монолитных системах
прямые вызовы и разделяемая память внутри него дают выигрыш в 
производительности?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5006ccff.6070...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-18 Пенетрантность Иван Лох

On Wed, Jul 18, 2012 at 06:49:35PM +0400, Артём Н. wrote:
 On 18.07.2012 00:49, Иван Лох wrote:
  On Tue, Jul 17, 2012 at 07:19:17PM +0400, Артём Н. wrote:
  On 17.07.2012 00:00, Artem Chuprina wrote:
  государства ровно в той же мере.
  М... Тогда откуда берутся те 30% именно на микроядерной архитектуре?
  Как минимум, надо парсить бесчисленные сообщения. 
 В плане того, что ядро - наиболее нагруженное место? И в монолитных системах
 прямые вызовы и разделяемая память внутри него дают выигрыш в 
 производительности?

Да. Например, в сетевой подсистеме.

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718210949.ga21...@nano.ioffe.rssi.ru

Re: Несколько вопросов вразброс

2012-07-17 Пенетрантность Artem Chuprina

Иван Лох - debian-russian@lists.debian.org @ Tue, 17 Jul 2012 01:37:29 +0400:

В функциональных языках - чистая. JS, а также Perl, Python etc. - языки
с _элементами_ функциональной парадигмы. Там функция - не first-class
entity, и количество возможных операций с нею сильно ограничено.

ИЛ Чем это функция в javascript не first-class объект? Вполне, себе.

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

Re: Несколько вопросов вразброс

2012-07-17 Пенетрантность Artem Chuprina

Артём Н. - debian-russian@lists.debian.org  @ Thu, 12 Jul 2012 20:31:32 +0400:

  Дык, кто же будет это читать... Нужна мотивация.
 АН Вы прям убили мою светлую идею на корню. :-D
 АН Я понимаю, что читать и разбирать по строчке нафиг никому не нужно.
 АН Общее впечатление: читабельно, нечитабельно,

Вон там первая строчка квотинга дает ответ на этот вопрос.  Нечитабельно.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87liiirgtn@wizzle.ran.pp.ru

Re: Несколько вопросов вразброс

2012-07-17 Пенетрантность Artem Chuprina

Артём Н. - debian-russian@lists.debian.org @ Fri, 13 Jul 2012 19:46:23 +0400:

Топик? IMHO, здесь рассылка по дебиану, а не школа юного программиста.
Одно другому мешает? :-)

Да. Я не хочу тратить своё время на разгребание кучи мусора.
Предпочитаю жить там, где мусора нет, а население культурно.
Вы конечно извините, но кто вас заставляет читать именно данную тему, раз
вы
считаете тут написанное мусором, оставленным некультурными людьми?

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

Понятно. Неуважение к собеседникам. В kill-file.

Re: Несколько вопросов вразброс

On 17.07.2012 00:00, Artem Chuprina wrote:
Артём Н. - debian-russian@lists.debian.org @ Sat, 07 Jul 2012 19:26:18
+0400:

-30% производительности -- минимальная цена.
Про IPC сообщениями? Они пишут, что производительность такая же, как
у и прямых
вызовов.
Это из известной статьи Таненбаума, где он сам признает, что
микроядерная архитектура
всегда даст среднюю потерю производительности около 30% на
intel-совместимых процессорах.
Он, конечно, уверяет, что это не важно.
АН Хм... Всё за счёт IPC? Даже, при грамотной организации IPC и узких
мест?
Межпроцессная защита, как и всякая другая защита, бесплатной не бывает.
АН Это только для микроядерной архитектуры справедливо?
Нет, конечно. Для линукса, для винды, и для полицейской системы
государства ровно в той же мере.
М... Тогда откуда берутся те 30% именно на микроядерной архитектуре?

Re: Несколько вопросов вразброс

On 16.07.2012 23:59, Artem Chuprina wrote:
В такой интерпретации ясно, что если в неком языке императивный
вычислитель явно не просматривается, то и от ОО-модели этот язык
не
особо выиграет.
АН Почему не выиграет?
Потому что их приткнуть либо некуда, либо незачем.
АН Для функциональных, опять же, понятно: есть функция. Объекты не
АН требуются. Инкапсуляция обеспечивается функцией. Наследование
АН заменяется агрегацией. Полиморфизм... Тоже может быть. Я очень
АН плохо знаком с функциональной парадигмой.
Полиморфизм поведенческий, а агрегация плюс полиморфизм - это уже
больше, чем наследование. Наследование оказывается как-то не очень
нужным.
АН Так, получается, это тоже самое наследование, только под другим углом?
Наоборот. Наследование, если смотреть на парадигму - это один из
(ограниченных) взглядов на полиморфизм.
Почему? Полиморфизм разве не является наследованием чего-либо, а наследование не
предполагает полиморфизм? Разве это не всегда совместно существующие вещи?

АН Как ни странно, замыкания поддерживает JS. :-) Естественно, встречалось.
И
АН нередко используется.
АН Но, насколько я понимаю, это получается уже не чистая функция...
В функциональных языках - чистая. JS, а также Perl, Python etc. - языки
с _элементами_ функциональной парадигмы. Там функция - не first-class
entity, и количество возможных операций с нею сильно ограничено.
Ну а разве сохранение состояния между вызовами не нарушает чистоты языка и не
может привести к каким-либо странным эффектам?

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

Т.е., в терминологии ООП, добавлять
общее поведение совершенно разнородным объектам. И всё вышеописанное
там делается совершенно не так, как в ООП. Вместо этот объект может
делать то-то и то-то так-то и так-то - эта сущность является частным
случаем вон той абстракции при взгляде вот под таким углом, и вот этой
абстракции - при взгляде вот под этим углом. Это, собственно, более
широкий взгляд на полиморфизм.
Т.е., нечто вроде множественного контекстно зависимого наследования?

Re: Несколько вопросов вразброс

On 16.07.2012 23:26, Artem Chuprina wrote:
А может и просто о
словоохотливости автора.
АН Читаю, как много воды.
Не обязательно. Сжатые формальные описания обычно очень трудно понять,
а чтобы описанным пользоваться, нужно наработать интуицию. Это наш мозг
умеет делать только через высокий уровень избыточности. Если автор
хорошо владеет словом, то его более толстая книга может быть усвоена
быстрее.
АН Хм... Если автор хорошо владеет словом и предметом, он может
АН уместить нужное в меньший объём. И это будет легко и понятно
АН читаться.
По сравнению с автором, плохо владеющим словом, при прочих равных, в
частности, _той же_ доступности результата.
Всё относительно. Мы и говорили про сравнение.

Чем
ниже он в книге, тем менее эта книга как таковая полезна для этой
наработки (обратное неверно). В смысле, придется делать больше
самостоятельных упражнений, чтобы усвоить материал.
Мда? Не соглашусь полностью. Разве большое количество самостоятельных упражнений
не помогает лучше усвоить материал? ;-) Как-то мне попадались сетования, что мы
учили ассемблер через debug, потому что литературы не было, а сейчас куча
книжек, но его никто не знает. Не потому что не нужен. :-) Просто потому, что
они действительно знают его лучше, чем прочитавшие книжку. Но и затраты больше.
Думаю, нужен баланс.

Re: Несколько вопросов вразброс

On 17.07.2012 11:25, Artem Chuprina wrote:
Артём Н. - debian-russian@lists.debian.org @ Fri, 13 Jul 2012 19:46:23
+0400:

Топик? IMHO, здесь рассылка по дебиану, а не школа юного
программиста.
Одно другому мешает? :-)

Да. Я не хочу тратить своё время на разгребание кучи мусора.
Предпочитаю жить там, где мусора нет, а население культурно.
Вы конечно извините, но кто вас заставляет читать именно данную тему,
раз вы
считаете тут написанное мусором, оставленным некультурными людьми?

Re: Несколько вопросов вразброс

On 17.07.2012 11:24, Artem Chuprina wrote:
 Артём Н. - debian-russian@lists.debian.org  @ Thu, 12 Jul 2012 20:31:32 
 +0400:
 
   Дык, кто же будет это читать... Нужна мотивация.
  АН Вы прям убили мою светлую идею на корню. :-D
  АН Я понимаю, что читать и разбирать по строчке нафиг никому не нужно.
  АН Общее впечатление: читабельно, нечитабельно,
 Вон там первая строчка квотинга дает ответ на этот вопрос.  Нечитабельно.
Тогда вопрос: почему? Комментарии есть. Код оформлен, как мне кажется, в
читаемом стиле. Трюков не применялось. Из-за чего?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500585f9.70...@yandex.ru

Re: Несколько вопросов вразброс

On 17.07.2012 00:02, Artem Chuprina wrote:
Артём Н. - debian-russian@lists.debian.org @ Sat, 07 Jul 2012 09:49:16
+0400:

Остаётся либо перехват функций (малопереносимый и чреватый некоторыми
последствиями) или ожидающий поток.
Какие ещё варианты?
Ты, наверно, хотел сказать, что в одной_известной_ос select есть только
для сокетов, и поэтому под неё писать сложнее. Но на это есть как раз
fileevent, который нужным образом реализован в языке, и работая с ним
нет необходимости заводить потоки вручную.
Я просто не помню есть ли в родном API этой известной ОС ожидание на
файлах...
Этим надо озаботиться до выбора инструмента для программирования.
АН Чем? Выбором ОС? А, обычно, кто-то спрашивает? :-(
За те задачи, где разработчику навязывают инструменты, браться не стоит.
Пусть их делает кто-то другой, у кого лишнего времени в жизни больше.
А есть задачи, где ничего не навязывают?

Да, кстати, вы так и не ответили насчёт Java и Ада...
Чем плох первый? И что возможно сказать о втором?

Re: Несколько вопросов вразброс

2012-07-17 Пенетрантность Иван Лох

On Tue, Jul 17, 2012 at 07:19:17PM +0400, Артём Н. wrote:
 On 17.07.2012 00:00, Artem Chuprina wrote:
  государства ровно в той же мере.
 М... Тогда откуда берутся те 30% именно на микроядерной архитектуре?

Как минимум, надо парсить бесчисленные сообщения. 

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120717204935.ga5...@nano.ioffe.rssi.ru

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Sun, 08 Jul 2012 21:23:57 +0400:

Неверно утверждение, что {} выполним, а строка - нет. И то, и другое
выполнимо, если попросить, и не выполнимо, если не просить. Различие,
собственно, во времени компиляции кода, и это очень существенное
различие.
АН Выполним в плане того, что он трактуется интерпретатором, как код.
АН В случае с eval - трактуется, как строка, со всеми вытекающими.
АН Я это хотел сказать.
Не интерпретатором, а компилятором. Интерпретатор как раз трактует их
одинаково - как код.
АН Ну да. Просто всё-таки Perl - интерпретируемый... Хотя, кажется он
АН и компилирует в промежуточный код.

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

А может и просто о
словоохотливости автора.
АН Читаю, как много воды.
Не обязательно. Сжатые формальные описания обычно очень трудно понять,
а чтобы описанным пользоваться, нужно наработать интуицию. Это наш мозг
умеет делать только через высокий уровень избыточности. Если автор
хорошо владеет словом, то его более толстая книга может быть усвоена
быстрее.
АН Хм... Если автор хорошо владеет словом и предметом, он может
АН уместить нужное в меньший объём. И это будет легко и понятно
АН читаться.

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

Re: Несколько вопросов вразброс

Stanislav Maslovski - debian-russian@lists.debian.org  @ Sun, 8 Jul 2012 
17:23:46 +0400:

 SM Ты явно хочешь свернуть с доказательства правильности *решения* задачи на
 SM доказательство правильности *постановки* задачи. Это отдельная
 SM проблема, которая формальными методами не решается *в принципе*.

В принципе - решается.  В теории следующего уровня :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d33vsdwc@wizzle.ran.pp.ru

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Wed, 11 Jul 2012 20:35:48 +0400:

Можно 1000 раз успешно прогнать *все*
комбинации входных переменных некой процедуры, а на 1001-м получить
ошибку, например, из-за утечки памяти, или из-за переполнения
какой-нибудь
переменной-счётчика, которая не обнуляется между вызовами, и т.п.
Значит не были протестированы _все_ состояния.
Задолбал! :)
Не, ну я здесь прав. ;-)
Нет. Повторюсь: построение *полного* теста в общем случае эквивалентно
решению
исходной программной задачи. Как ты собираешься доказывать правильность
самого теста? Ещё одним тестом? И так до бесконечности?
АН М... Ну да. Про тест я не подумал. Но, если тест - просто тупой
АН перебиратель результата..?

Тогда программа - это тупой lookup в таблице. Раз все возможные
результаты нам известны заранее.

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Sat, 07 Jul 2012 19:43:34 +0400:

В пределе, вероятно, да. В процессе - нет. А поскольку мы всегда в
процессе...

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

Проблема не в том, что задачи сложны, а в том, что людям лень думать так
называемой головой. Когда заказчик сам не знает, чего хочет, но хочет,
чтоб работало - да, ООП оправдан. И то не всегда. КАК ТОЛЬКО
архитектор системы может сделать с постановкой задачи что-то осмысленное
- скорее всего, ООП окажется не самым подходящим инструментом. Хотя с
этим подходом тоже можно решить задачу, почему нет? Дрель с ударом
тоже может делать отверстия под дюбели в бетоне. Только ею приходится
долбать одно отверстие 5 минут, а перфоратор справляется за 15 секунд.
Если дырок нужно набурить хотя бы три, не говоря про два десятка,
разница становится ОЧЕНЬ существенной. Но если ты не знаешь заранее,
что тебе надо будет сверлить - бетон, асбест или дерево, а взять можно
только один инструмент (хотя бы по массогабаритным ограничениям), то
лучше взять дрель - под перфоратор бура по дереву тупо нет. А если
можно взять два, то лучше дрель (можно без удара, читай, C, а не C++) и
перфоратор.

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

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

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

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org  @ Sat, 07 Jul 2012 19:26:18 +0400:

-30% производительности -- минимальная цена.
Про IPC сообщениями? Они пишут, что производительность такая же, как у 
  и прямых
вызовов.
Это из известной статьи Таненбаума, где он сам признает, что 
  микроядерная архитектура
всегда даст среднюю потерю производительности около 30% на 
  intel-совместимых процессорах.
Он, конечно, уверяет, что это не важно.
   АН Хм... Всё за счёт IPC? Даже, при грамотной организации IPC и узких 
  мест?
  Межпроцессная защита, как и всякая другая защита, бесплатной не бывает.
 АН Это только для микроядерной архитектуры справедливо?

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk6zqxvp@wizzle.ran.pp.ru

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Sat, 07 Jul 2012 09:49:16 +0400:

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

Re: Несколько вопросов вразброс

2012-07-16 Пенетрантность Иван Лох

On Mon, Jul 16, 2012 at 11:59:50PM +0400, Artem Chuprina wrote:
 
 В функциональных языках - чистая.  JS, а также Perl, Python etc. - языки
 с _элементами_ функциональной парадигмы.  Там функция - не first-class
 entity, и количество возможных операций с нею сильно ограничено.

Чем это функция в javascript не first-class объект? Вполне, себе.  

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120716213729.ge11...@nano.ioffe.rssi.ru

Re: Несколько вопросов вразброс

2012-07-13 Пенетрантность Igor Chumak


12.07.2012 17:14, Артём Н. пишет:

Больше, конечно, интересно, что по основному скрипту..?


500 строк кода, который можно переписать хоть на perl, хоть на С. 
Ниасилил ;)


Мое ИМХО:

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



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fffcdb8.2070...@gmail.com

Re: Несколько вопросов вразброс

2012-07-13 Пенетрантность Артём Н.

On 12.07.2012 23:50, Eugene Berdnikov wrote:
On Thu, Jul 12, 2012 at 10:48:05PM +0400, Артём Н. wrote:
On 12.07.2012 22:39, Eugene Berdnikov wrote:
On Thu, Jul 12, 2012 at 10:17:49PM +0400, Артём Н. wrote:
On 12.07.2012 22:11, Eugene Berdnikov wrote:

Топик? IMHO, здесь рассылка по дебиану, а не школа юного программиста.
Одно другому мешает? :-)

Да. Я не хочу тратить своё время на разгребание кучи мусора.
Предпочитаю жить там, где мусора нет, а население культурно.
Вы конечно извините, но кто вас заставляет читать именно данную тему, раз вы
считаете тут написанное мусором, оставленным некультурными людьми?

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

Re: Несколько вопросов вразброс

2012-07-13 Пенетрантность Артём Н.

On 13.07.2012 11:26, Igor Chumak wrote:
12.07.2012 17:14, Артём Н. пишет:
Больше, конечно, интересно, что по основному скрипту..?
500 строк кода, который можно переписать хоть на perl, хоть на С.
Ну это само собой. Но делать оболочку на C - не самый красивый вариант.
Про Perl, я уже говорил: зачем переписывать?

Мое ИМХО:
Для генерации выполняемого кода из исходного есть компилятор; делать свой
компилятор на sed/awk только для того, чтобы выкусить тестировочный код -
изврат.\
Возможно. Но не оставлять же его в скрипте?

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

Re: Несколько вопросов вразброс

2012-07-13 Пенетрантность Igor Chumak

13.07.2012 22:34 пользователь Артём Н. artio...@yandex.ru написал:

 On 13.07.2012 11:26, Igor Chumak wrote:
  12.07.2012 17:14, Артём Н. пишет:
  Больше, конечно, интересно, что по основному скрипту..?
  500 строк кода, который можно переписать хоть на perl, хоть на С.
 Ну это само собой. Но делать оболочку на C - не самый красивый вариант.
 Про Perl, я уже говорил: зачем переписывать?

Код написан в сишном стиле ;) можно переписать , если захочется извратов,
шеллу недоступных.


  Мое ИМХО:
  Для генерации выполняемого кода из исходного есть компилятор; делать
свой
  компилятор на sed/awk только для того, чтобы выкусить тестировочный
код - изврат.\
 Возможно. Но не оставлять же его в скрипте?

Есть if, есть include

Re: Несколько вопросов вразброс

On Wed, Jul 11, 2012 at 10:36:22PM +0400, Артём Н. wrote:
 Приложил скрипт, который у меня получился.
 mkbackup - сам скрипт.
 mks  - парсер, убирающий тесты.
 ready- готовый скрипт после обработки.
 
 Вроде, работает, хотя и не всё доделано.
 Ощущения: получилось очень тяжеловесно.

[кусь]

 #!/bin/sh
 
 fl=$1
 fl=${-:-$fl}
 
 awk '
BEGIN {
   prf = 0;
}
 
/^#!\/bin\/bash/ {
   print #!/bin/sh;
   next;
}
 
/###TESTING/ {
   prf = pfm + 1;
   next;
}
 
/###\/TESTING/ {
   if (prf == 0)
   {
  print Error: unexpected ###\/TESTING  /dev/stderr;
  exit 1;
   }
   prf = prf - 1;
   next;
}
 
{
   if (prf == 0) print;
}
 
END {
   if (prf  0)
   {
  print Error: unclosed ###TESTING;
  exit 1;
   }
}
 ' $fl

Жесть.

$ sed -e '1s/#!\/bin\/bash/#!\/bin\/sh/;/###TESTING/,/###\/TESTING/d' mkbackup 
 ready

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712085042.GA7892@kaiba.homelan

Re: Несколько вопросов вразброс

On 12.07.2012 12:50, Stanislav Maslovski wrote:
 On Wed, Jul 11, 2012 at 10:36:22PM +0400, Артём Н. wrote:
 Приложил скрипт, который у меня получился.
 mkbackup - сам скрипт.
 mks  - парсер, убирающий тесты.
 ready- готовый скрипт после обработки.

 Вроде, работает, хотя и не всё доделано.
 Ощущения: получилось очень тяжеловесно.
 
 [кусь]
 
 #!/bin/sh

 fl=$1
 fl=${-:-$fl}

 awk '
BEGIN {
   prf = 0;
}

/^#!\/bin\/bash/ {
   print #!/bin/sh;
   next;
}

/###TESTING/ {
   prf = pfm + 1;
   next;
}

/###\/TESTING/ {
   if (prf == 0)
   {
  print Error: unexpected ###\/TESTING  /dev/stderr;
  exit 1;
   }
   prf = prf - 1;
   next;
}

{
   if (prf == 0) print;
}

END {
   if (prf  0)
   {
  print Error: unclosed ###TESTING;
  exit 1;
   }
}
 ' $fl
 
 Жесть.
 
 $ sed -e '1s/#!\/bin\/bash/#!\/bin\/sh/;/###TESTING/,/###\/TESTING/d' 
 mkbackup  ready
Вложенность не поддерживается (может быть не закрытый тег). :-D
А, вообще, awk мне просто понятнее и привычнее.
Это дело вкуса.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffed947.6030...@yandex.ru

Re: Несколько вопросов вразброс

Больше, конечно, интересно, что по основному скрипту..?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffedbd8.6070...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-12 Пенетрантность Igor Chumak

11.07.2012 19:24, Артём Н. пишет:

On 11.07.2012 01:08, Igor Chumak wrote:

-Куть

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

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

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

Я не про показ статистики, а именно про возврат кода.

Результат работы функции не обязательно short int ;)
Если очень хочется именно _кода_ - можно вернуть % успешно выполненных
задач.

Можно писать ошибки в глобальный массив, в конце работы его анализировать.

М... Снова глобальный. :-|

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

Код возврата, вызванной программы, видимо, не вариант. Сделал на флагах.
Чтобы было понятно в какой функции произошла ошибка. Но как-то...
А как правильно?

Как сказано было выше, у perl есть use Carp; задачу определить в какой функции
ошибка поможет решить

Про Perl буду знать. Но, увы, в моём случае: shell.

Зачем такое ограничение??

Хотя в bash тоже есть
FUNCNAME
An array variable containing the names of all shell
functions currently in the execution call stack.

Делаем функцию die(), которая анализирует и печатает FUNCNAME. Why not?

Re: Несколько вопросов вразброс

On 12.07.2012 02:55, Stanislav Maslovski wrote:
On Wed, Jul 11, 2012 at 08:35:48PM +0400, Артём Н. wrote:
On 11.07.2012 04:18, Stanislav Maslovski wrote:
Они есть. Этого уже достаточно.
Недостаточно. Достаточно было бы, если бы их на практике было просто
применить... Часто ли это применяется и просто ли?
Применяется в mission-critical systems, насколько часто и насколько
просто - вопрос скорее к тем, кто этими системами плотно занимается.
Эм... Точно. Спрошу.

Нет. Повторюсь: построение *полного* теста в общем случае эквивалентно
решению
исходной программной задачи. Как ты собираешься доказывать правильность
самого теста? Ещё одним тестом? И так до бесконечности?
М... Ну да. Про тест я не подумал. Но, если тест - просто тупой перебиратель
результата..?
В таком случае, и сама программная задача тупа в той же мере, в какой
туп ее *полный* тест.
Я подумал о следующем варианте...
1. Есть программа, которая получает данные (к примеру, пакет фиксированного
размера из сети).
2. Она обрабатывает данные (это чёрный ящик), в зависимости от того, что
поступило на вход и того, что поступало ранее (но память ограничена).
3. При её запуске состояние всегда одинаковое (не ведётся база или всегда
обнуляется).
4. На выходе - пакет.
5. Программа не учитывает временные характеристики, поступающих данных.

Пакет - число определённой разрядности. Длина, в данном случае, фиксирована.
Обработка может быть сколь угодно сложной (например, это модуль ЦОС, принимающий
данные от АЦП).

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

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

И сомнительно это.

Вот тебе элементарный пример: докажи теорему Пифагора *тестами* =)
Возможно повысить уверенность в том, что алгоритм доказательства теоремы
реализован правильно, используя тесты.
Это ещё что за новая сущность? алгоритм доказательства теоремы?
Я именно про конкретный случай. Есть доказательство по опр. алгоритму.
Тесты позволят повысить уверенность в нём.
Я - пас :) Желающие продолжить - велкам.
Ну, хорошо. :-D
В общем-то, про тесты, во многом я согласен, просто поспорить охота.
Тут, кажется, есть достаточно определённое решение:
1. Естественно, никакого доказательства тестами нет (я про такое и не писал),
если тесты не могут покрыть всю область определения.
2. Писать тесты лучше, чем не писать тесты.
3. У тестов есть один серьёзный минус: сложная задача требует сложных тестов. И,
как выясняется, объём тестов сопоставим с объёмом задачи, а в некоторых случаях,
даже больше.
4. Пункт 3 заставляет серьёзно подумать над пунктом 2.
5. Если возможно однозначно доказать корректность, то тест проще выкинуть, чем
поддерживать. Да он и не требуется.

Но смущают некоторые вещи:
1. TDD. Ведь оно существует? Вероятно, оно создавалось для больших проектов.
Где-нибудь используется?
2. Но ведь модульное тестирование продвигается и приветствуется...

Re: Несколько вопросов вразброс

On 12.07.2012 18:29, Igor Chumak wrote:
11.07.2012 19:24, Артём Н. пишет:
On 11.07.2012 01:08, Igor Chumak wrote:
-Куть
Это если ты делаешь ошибку, которую тест уже ловит. А если ты делаешь
ошибку, которую тест еще не ловит (а она будет, и не одна), то результат
будет тот же самый, как если бы теста не было вообще. Внятная и
подробная диагностика поэтому обязательна.
Я и делаю. Как-раз хотел спросить (очередной провокационный вопрос).
Как организовывать обработку ошибок?:-)
Т.е., вызывается функция. Она должна вернуть код завершения.
В функции м.б. вложенные функции.
В функции может выполниться только часть вызовов вложенных функций.
К примеру, бэкап БД не прошёл, но бэкап состояния пакетов, который делается
следующим, должен быть сделан.
Какой код возвращать?
Обычно возвращают статистику время выполнения, сколько задач в задании
провалилось, сколько файлов скопировано, сколько байт прочитано, сколько
записано Если какая-то часть логики вынесена в функцию,значит
результат ее
должен что-то означать?
Я не про показ статистики, а именно про возврат кода.
Результат работы функции не обязательно short int ;)
Если очень хочется именно _кода_ - можно вернуть % успешно выполненных задач.
Но что он даст? Я же не смогу определить какие задачи провалились...

Можно писать ошибки в глобальный массив, в конце работы его анализировать.
М... Снова глобальный. :-|

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

Код возврата, вызванной программы, видимо, не вариант. Сделал на флагах.
Чтобы было понятно в какой функции произошла ошибка. Но как-то...
А как правильно?
Как сказано было выше, у perl есть use Carp; задачу определить в какой
функции
ошибка поможет решить
Про Perl буду знать. Но, увы, в моём случае: shell.
Зачем такое ограничение??
Сейчас у меня уже есть скриптик на нём. Не переделывать же на Perl, который я не
знаю? К тому же, в данном случае (при попытке попробовать), ограничение лишним
не будет (ведь этот модуль очень специфичная для Perl вещь, которой нет в
большинстве языков).

Хотя в bash тоже есть
FUNCNAME
An array variable containing the names of all shell functions
currently in the execution call stack.
И я его использую. См. скрипт в треде.

Делаем функцию die(), которая анализирует и печатает FUNCNAME. Why not?
Нельзя сдыхать. В этом проблема. :-) Если бы возможно было завершить функцию, то
никаких проблем. А меня интересует более общий случай. К тому же, печатать - не
всегда вариант. Хотя... Может.

Re: Несколько вопросов вразброс

On Thu, Jul 12, 2012 at 06:14:48PM +0400, Артём Н. wrote:
 Больше, конечно, интересно, что по основному скрипту..?

Дык, кто же будет это читать... Нужна мотивация.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712161635.GA18587@kaiba.homelan

Re: Несколько вопросов вразброс

On Thu, Jul 12, 2012 at 06:03:51PM +0400, Артём Н. wrote:
 On 12.07.2012 12:50, Stanislav Maslovski wrote:
  $ sed -e '1s/#!\/bin\/bash/#!\/bin\/sh/;/###TESTING/,/###\/TESTING/d' 
  mkbackup  ready
 Вложенность не поддерживается (может быть не закрытый тег). :-D

Вложенность, вероятно, нужна для того, чтобы в тесты встраивать тесты
тестов ;)

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712162038.GB18587@kaiba.homelan

Re: Несколько вопросов вразброс

 Дык, кто же будет это читать... Нужна мотивация.
Вы прям убили мою светлую идею на корню. :-D
Я понимаю, что читать и разбирать по строчке нафиг никому не нужно.
Общее впечатление: читабельно, нечитабельно, читабельно ли без тестов, помогают
ли они там (без учёта того, что ну это возможно было и без тестов (и ответить,
как известно, возможно: если код заслуживает быть написанным...)), что плохо с
первого взгляда, что стоит изменить?

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffefbe4.5060...@yandex.ru

Re: Несколько вопросов вразброс

On 12.07.2012 20:20, Stanislav Maslovski wrote:
 On Thu, Jul 12, 2012 at 06:03:51PM +0400, Артём Н. wrote:
 On 12.07.2012 12:50, Stanislav Maslovski wrote:
 $ sed -e '1s/#!\/bin\/bash/#!\/bin\/sh/;/###TESTING/,/###\/TESTING/d' 
 mkbackup  ready
 Вложенность не поддерживается (может быть не закрытый тег). :-D
 Вложенность, вероятно, нужна для того, чтобы в тесты встраивать тесты
 тестов ;)
Зря смеётесь. У меня, конечно, этого нет. :-\ Но я видел: реально делают тесты
для тестов (для основных тестов).


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffefc13.6070...@yandex.ru

Re: Несколько вопросов вразброс

Да, из хороших впечатлений: если что-то ломается, тест это отлавливает.
Без теста мне бы потребовалось больше времени.
Но однозначного ответа: стоят ли тесты того, чтобы их писать, лучше ли сильно
неполное покрытие, чем никакое и оправдана ли TTD, у меня так и нет... :-(


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffefca8.7040...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-12 Пенетрантность Dmitry Nezhevenko

On 06.07.2012 00:07, Artem Chuprina wrote:
Артём Н. - debian-russian@lists.debian.org @ Thu, 05 Jul 2012 20:49:27
+0400:

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

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

Хочешь писать хорошие программы - изучи несколько парадигм, и применяй
наиболее подходящие к задаче. А не суй где надо и где не надо ту
единственную, которую ты знаешь.
АН Плохо то, что единственной парадигмы, подходящей везде, - нет.
Извини, это в некотором смысле объективный закон. Что-то вроде закона
всемирного тяготения. Не просто нет, а доказуемо не может быть.
АН Ну везде, с некоторыми ограничениями...
Все зависит от ограничений ;-) Классическое автомобиль может быть
любого цвета, если этот цвет черный - это тоже с некоторым
ограничением.
И, тем не менее, в данном случае ограничение оказалось успешным. Причём, затем,
его убрали. А идея, подходящая почти под любое производство осталась...
Хотя, да. Идея для специфических задач: тех, которые возможно поставить на
поток.

Помнится, код, переписанный с C++ на C со старательным
выкидыванием всей
объектности, кроме нужной, стал на порядок компактнее, вдвое
понятнее, и
давал в разы меньший результат при компиляции.
Tcl - он же функциональный по сути, зачем ему объекты?
АН Хм... Честно не знаю. Объекты, в принципе, не лишние. Но как
совмещается
АН объектный и функциональный подход..? Хотя, библиотеки-то
есть...
Никогда не надо пользоваться тем, что в принципе не лишнее.
Пользоваться надо только тем, что тебе действительно нужно, и
понимая,
почему именно оно, а не альтернативы.
АН Да, бритву Оккама не отменяли. :-) Но, во-первых, не всегда
АН возможно выбрать лучшую из альтернатив, потому что обе они имеют
АН взаимокомпенсирующие достоинства и недостатки, так что, ни одна
из
АН них не является лучшей. Во-вторых, иногда просто недостаточно
АН информации для выбора.
Я видел только один вариант недостаточно информации для выбора -
незнание альтернатив.
АН Нет, почему же?
АН Незнание всех характеристик альтернатив, незнание того, как поведёт
АН себя данная альтернатива, незнание того насколько сильнее одна
АН характеристика влияет на абстрактное качество системы, чем
АН другая. Много что возможно не знать.
Перечисленное тобой либо сводится к незнанию альтернатив (не знаешь как
поведет - ну, попробуй на тестовом примере; если тебе это слишком сложно
или дорого, это значит, что ты знаешь о существовании этой альтернативы,
но не знаешь ее саму), либо к задачам, которые решать не надо
(совершенно не нужно оценивать влияние характеристик на абстрактное
качество системы, если тебе нужно, чтобы система работала - тебе может
быть интересно только несколько _конкретных_ качеств).
АН В общем случае, да. Но незнание альтернатив почти всегда есть.
При наличии образования - отнюдь не почти всегда. Конечно, чтобы
правильно задать вопрос, надо знать половину ответа. Но затем и
образование.
Хех. Что даёт образование? Вы правда в него верите? Веком ранее так не считали?
Да и в каком плане образования и какого? :-)

Важный момент: совершенно не обязательно выбирать
лучшую из альтернатив. Если ты не можешь решить, которая из
нескольких
лучше по описанной причине, это по крайней мере значит, что ни одна из
них не будет существенно хуже других. Выбери любую.
АН Ага. И тут получается проблема буриданова осла. Принятие решения.
:-)
Монетку брось.
АН Не то...
KISS!
Ну да. Забываю.

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

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

Если ты не можешь изучить задачу до этого уровня - ты ее не

Re: Несколько вопросов вразброс

On Thu, Jul 12, 2012 at 08:59:14PM +0400, Артём Н. wrote:
 
 Я не вижу ни отсутствия надёжности, ни медлительности. Где?
 И пример - тот же апач. Вариант без потоков?

nginx/lighttpd умеют в одном потоке пачку соединений обрабатывать. Ибо
FSM. 
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

On 12.07.2012 21:07, Dmitry Nezhevenko wrote:
 On Thu, Jul 12, 2012 at 08:59:14PM +0400, Артём Н. wrote:

 Я не вижу ни отсутствия надёжности, ни медлительности. Где?
 И пример - тот же апач. Вариант без потоков?
 
 nginx/lighttpd умеют в одном потоке пачку соединений обрабатывать. Ибо
 FSM. 
Хм... Посмотрел. lighttpd, кажется, серьёзный сервер (судя по тому, где
используется).
Но что значит обрабатывать? Подключения? Или отдачу данных?
И ведь, всё-равно, они отдают данные, в этом случае, последовательно, а если
соединений будет много, будут задержки..?
Или они там наподобие планировщика своего что-то сделали?
И как распараллелить, ведь наверняка там всё-равно используются потоки (просто в
одном потоке обрабатывается несколько соединений)?
И причём здесь FSM (как я понял, это простой советский конечный автомат)?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fff079e.20...@yandex.ru

Re: Несколько вопросов вразброс

On Thu, Jul 12, 2012 at 08:31:32PM +0400, Артём Н. wrote:
 У меня сложилось ощущение, что тесты сильно затягивают время, требуемое на
 написание. Причём, если меняется функция, часто требуется менять и тест. Ещё я
 заметил, что в тестах тоже бывают ошибки, поэтому их надо проверять...

Артём, я думаю, эта тема с тестами уже всех тут замонала. Пора
возвращаться ближе к топику.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712172455.GA22728@kaiba.homelan

Re: Несколько вопросов вразброс

2012-07-12 Пенетрантность Eugene Berdnikov

On 12.07.2012 21:24, Stanislav Maslovski wrote:
 On Thu, Jul 12, 2012 at 08:31:32PM +0400, Артём Н. wrote:
 У меня сложилось ощущение, что тесты сильно затягивают время, требуемое на
 написание. Причём, если меняется функция, часто требуется менять и тест. Ещё 
 я
 заметил, что в тестах тоже бывают ошибки, поэтому их надо проверять...
 
 Артём, я думаю, эта тема с тестами уже всех тут замонала. Пора
 возвращаться ближе к топику.
Ээээ... О чём он был? o.O


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fff0e70.5010...@yandex.ru

Re: Несколько вопросов вразброс

On Thu, Jul 12, 2012 at 09:50:40PM +0400, Артём Н. wrote:
 On 12.07.2012 21:24, Stanislav Maslovski wrote:
  On Thu, Jul 12, 2012 at 08:31:32PM +0400, Артём Н. wrote:
  У меня сложилось ощущение, что тесты сильно затягивают время, требуемое на
  написание. Причём, если меняется функция, часто требуется менять и тест. 
  Ещё я
  заметил, что в тестах тоже бывают ошибки, поэтому их надо проверять...
  
  Артём, я думаю, эта тема с тестами уже всех тут замонала. Пора
  возвращаться ближе к топику.
 Ээээ... О чём он был? o.O

 Топик? IMHO, здесь рассылка по дебиану, а не школа юного программиста.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712181139.gd3...@sie.protva.ru

Re: Несколько вопросов вразброс

2012-07-12 Пенетрантность Eugene Berdnikov

On 12.07.2012 22:11, Eugene Berdnikov wrote:
 On Thu, Jul 12, 2012 at 09:50:40PM +0400, Артём Н. wrote:
 On 12.07.2012 21:24, Stanislav Maslovski wrote:
 On Thu, Jul 12, 2012 at 08:31:32PM +0400, Артём Н. wrote:
 У меня сложилось ощущение, что тесты сильно затягивают время, требуемое на
 написание. Причём, если меняется функция, часто требуется менять и тест. 
 Ещё я
 заметил, что в тестах тоже бывают ошибки, поэтому их надо проверять...

 Артём, я думаю, эта тема с тестами уже всех тут замонала. Пора
 возвращаться ближе к топику.
 Ээээ... О чём он был? o.O
 
  Топик? IMHO, здесь рассылка по дебиану, а не школа юного программиста.
Одно другому мешает? :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fff14cd.5010...@yandex.ru

Re: Несколько вопросов вразброс

On Thu, Jul 12, 2012 at 10:17:49PM +0400, Артём Н. wrote:
 On 12.07.2012 22:11, Eugene Berdnikov wrote:
  
   Топик? IMHO, здесь рассылка по дебиану, а не школа юного программиста.
 Одно другому мешает? :-)

 Да. Я не хочу тратить своё время на разгребание кучи мусора.
 Предпочитаю жить там, где мусора нет, а население культурно.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712183941.ge3...@sie.protva.ru

Re: Несколько вопросов вразброс

On 12.07.2012 22:39, Eugene Berdnikov wrote:
 On Thu, Jul 12, 2012 at 10:17:49PM +0400, Артём Н. wrote:
 On 12.07.2012 22:11, Eugene Berdnikov wrote:

  Топик? IMHO, здесь рассылка по дебиану, а не школа юного программиста.
 Одно другому мешает? :-)
 
  Да. Я не хочу тратить своё время на разгребание кучи мусора.
  Предпочитаю жить там, где мусора нет, а население культурно.
Вы конечно извините, но кто вас заставляет читать именно данную тему, раз вы
считаете тут написанное мусором, оставленным некультурными людьми?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fff1be5.6050...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-12 Пенетрантность Eugene Berdnikov

On Thu, Jul 12, 2012 at 09:50:40PM +0400, Артём Н. wrote:
 On 12.07.2012 21:24, Stanislav Maslovski wrote:
  On Thu, Jul 12, 2012 at 08:31:32PM +0400, Артём Н. wrote:
  У меня сложилось ощущение, что тесты сильно затягивают время, требуемое на
  написание. Причём, если меняется функция, часто требуется менять и тест. 
  Ещё я
  заметил, что в тестах тоже бывают ошибки, поэтому их надо проверять...
  
  Артём, я думаю, эта тема с тестами уже всех тут замонала. Пора
  возвращаться ближе к топику.
 Ээээ... О чём он был? o.O.

Я про рассылку в целом, а не про этот конкретный тред.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712185301.GA25399@kaiba.homelan

Re: Несколько вопросов вразброс

On Thu, Jul 12, 2012 at 10:48:05PM +0400, Артём Н. wrote:
On 12.07.2012 22:39, Eugene Berdnikov wrote:
On Thu, Jul 12, 2012 at 10:17:49PM +0400, Артём Н. wrote:
On 12.07.2012 22:11, Eugene Berdnikov wrote:

Топик? IMHO, здесь рассылка по дебиану, а не школа юного программиста.
Одно другому мешает? :-)

Да. Я не хочу тратить своё время на разгребание кучи мусора.
Предпочитаю жить там, где мусора нет, а население культурно.
Вы конечно извините, но кто вас заставляет читать именно данную тему, раз вы
считаете тут написанное мусором, оставленным некультурными людьми?

Re: Несколько вопросов вразброс

On 11.07.2012 01:08, Igor Chumak wrote:
-Куть
Это если ты делаешь ошибку, которую тест уже ловит. А если ты делаешь
ошибку, которую тест еще не ловит (а она будет, и не одна), то результат
будет тот же самый, как если бы теста не было вообще. Внятная и
подробная диагностика поэтому обязательна.
Я и делаю. Как-раз хотел спросить (очередной провокационный вопрос).
Как организовывать обработку ошибок? :-)
Т.е., вызывается функция. Она должна вернуть код завершения.
В функции м.б. вложенные функции.
В функции может выполниться только часть вызовов вложенных функций.
К примеру, бэкап БД не прошёл, но бэкап состояния пакетов, который делается
следующим, должен быть сделан.
Какой код возвращать?
Обычно возвращают статистику время выполнения, сколько задач в задании
провалилось, сколько файлов скопировано, сколько байт прочитано, сколько
записано Если какая-то часть логики вынесена в функцию,значит результат
ее
должен что-то означать?
Я не про показ статистики, а именно про возврат кода.

Можно писать ошибки в глобальный массив, в конце работы его анализировать.
М... Снова глобальный. :-|

Re: Несколько вопросов вразброс

On 11.07.2012 04:18, Stanislav Maslovski wrote:
On Tue, Jul 10, 2012 at 09:53:02PM +0400, Артём Н. wrote:
On 08.07.2012 17:23, Stanislav Maslovski wrote:
На практике ситуация такова: случаев, где возможно *полное* формальное
доказательство правильности программы *больше*, чем случаев, где для этого
достаточно *простых* тестов.
Как правило, построение *полного* теста эквивалентно решению исходной
программной задачи, и, поэтому, не имеет никакой ценности для
доказательства.
Понятно. А вообще, случаев, когда:
1. возможно полное доказательство;
2. доказательство имеет практическое значение;
много?
Они есть. Этого уже достаточно.
Недостаточно. Достаточно было бы, если бы их на практике было просто
применить... Часто ли это применяется и просто ли?

Можно 1000 раз успешно прогнать *все*
комбинации входных переменных некой процедуры, а на 1001-м получить
ошибку, например, из-за утечки памяти, или из-за переполнения какой-нибудь
переменной-счётчика, которая не обнуляется между вызовами, и т.п.
Значит не были протестированы _все_ состояния.
Задолбал! :)
Не, ну я здесь прав. ;-)
Нет. Повторюсь: построение *полного* теста в общем случае эквивалентно решению
исходной программной задачи. Как ты собираешься доказывать правильность
самого теста? Ещё одним тестом? И так до бесконечности?
М... Ну да. Про тест я не подумал. Но, если тест - просто тупой перебиратель
результата..? Т.е., в итоге-то поведение программы всё-равно определяется тем,
что подали на входы (да, если не брать в расчёт временные характеристики
изменения входов)?

Вот тебе элементарный пример: докажи теорему Пифагора *тестами* =)
Возможно повысить уверенность в том, что алгоритм доказательства теоремы
реализован правильно, используя тесты.
Это ещё что за новая сущность? алгоритм доказательства теоремы?
Я именно про конкретный случай. Есть доказательство по опр. алгоритму. Тесты
позволят повысить уверенность в нём. Сейчас вспомнил, что за теорема. :-)
Например, в вики приведён пример док-ва через подобные треугольники.
И там a/c = |HB|/a, где H - точка деления гипотенузы c высотой.
В тесте возможно было бы задать конкретный треугольник через a, b и c, затем
вычислить нахождение точки H и проверить утверждение.
В данном случае, конечно, доказательство общеизвестное и сводится к теореме,
которая также доказывается общеизвестным доказательством...
Но ведь возможно, что доказательство неверно, где-то ошибка?
Тест поможет проверить несколько вариантов.
Имеет смысл его вводить?

Про доказательство тестами я ничего не писал. :-)
Да ну? А как же пресловутая проверка по всем состояниям?
Это в теории. :-)

Re: Несколько вопросов вразброс

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffdac20.2080...@yandex.ru

Re: Несколько вопросов вразброс

2012-07-11 Пенетрантность Stanislav Maslovski

Приложил скрипт, который у меня получился.
mkbackup - сам скрипт.
mks  - парсер, убирающий тесты.
ready- готовый скрипт после обработки.

Вроде, работает, хотя и не всё доделано.
Ощущения: получилось очень тяжеловесно. Просто запутаться в тестах. Но тесты
ловят случайные ошибки (лучше, чем без тестов совсем).

Что скажете?
#!/bin/sh

#
# Backup script, used rdiff-backup. Created by Artiom N..
#

# Using: mkbackup path to config

# Configuration options.
OPT_SRC_DIR=/
OPT_BACKUP_DIR=/mnt/backup/backup_uc
OPT_BTMP_DIR=/mnt/backup/btmp
OPT_INC_LIST=include.cfg
OPT_EXC_LIST=exclude.cfg
OPT_MYSQL_LOGIN=root
OPT_MYSQL_PASSWORD=
OPT_LUKS_PARTS=
OPT_KERNEL_CONFIG=/usr/src/linux/.config
OPT_REMOVE_PERIOD=1M

OPT_FBACKUP_KCONF=true
OPT_FBACKUP_MYSQL=true
OPT_FBACKUP_PACKAGES=true
OPT_FBACKUP_PARTS=true

# Verbosity: 0 - no diagnostics, 1 - error messages, 2 - verbose, 3 - debug.
V_LEVEL=3

# Resulting filename constants.
FN_MYSQL_DUMP=mysql.dump
FN_PKGS_DUMP=pagkages.dump
FN_LVM_TEMPL=lvbk_%s
FN_LUKS_TEMPL=luksbk_%s
FN_KERNEL_CONF=linux_config

# Directories in $OPT_BACKUP_DIR for backup system tree and special files.
FN_DIR_TREE=tree
FN_DIR_SPECIAL=special

# File or directory, used as flag, for selecting backup type.
FN_FLAG=rdiff-backup-data

# Binaries path.
CMD_DPKG=dpkg
CMD_VGBCK=vgcfgbackup
CMD_DUMP=mysqldump
CMD_CRYPTSETUP=cryptsetup
CMD_RDBCKP=rdiff-backup
CMD_NOTIFIER=logger

###TESTING
assert()
# $1 - message;
# $2 - comannd.
{
   local RT=0
   echo Command: $2
   eval $2 || { RT=$?; printf $1 (ret: 0x%x) $RT  exit 1; }
   return 0;
}
###/TESTING
#---
dbg()
# $1 - verbosity level;
# $2 - message.
{
   [ $V_LEVEL -ge $1 ]  echo $2  /dev/stderr
}
#---
err()
# $1 - message.
{
   dbg 1 $1
   dbg 0 Backup failed... # failed... exit 1
   return 1
}
###TESTING
#---
check_deps()
# Check for the using executables.
# $1..$n - list of executables.
{
   local s
   while [ ! -z $1 ]; do
  s=`type $1`  dbg 3 Checking dep $s || { dbg 1 $s  return 1; }
  shift
   done;

   return 0;
}
###/TESTING
#---
get_execs()
# Set full path of the executables in the variables.
# $1..$n - list of executables.
{
   local s
   while [ ! -z $1 ]; do
  eval s=\$$1
  dbg 3 Exec filename: $s
  s=$(whereis -b $s|awk '{print $2}')
  dbg 3 Exec fullpath: $s
  [ -z $s ]  { err Cant't find \eval \$$1\; return 1; }
  eval $1=$s
  shift
   done
   return 0;
}
#---
load_config()
# $1 - config filename.
{
   dbg 3 $LINENO ${FUNCNAME}(): Loading file \$1\
   dbg 3 PWD: $PWD
   [ -r $1 ] || { err Can't open file \$1\...; return 1; }
   . $1 || return $?
   
   return $?;
}
#---
notify()
# Notify user, about backup process.
# $1 - message.
{
   $CMD_NOTIFIER $1
   return 0;
}
#---
backup_special()
# Backup special system data.
# Return values:
# $?  0x000f - backup_kernel_conf result;
# $?  0x00f0 - backup_mysql result;
# $?  0x0f00 - backup_packages result;
# $?  0xf000 - backup_parted_data result.
{

   #
   # Interfaces.
   #

   backup_mysql()
   # $1 - user name;
   # $2 - password;
   # $3 - options.
   # Return 0, if all good, 1 if error.
   {
  dbg 3 $LINENO ${FUNCNAME}(): Loading MySQL config...
  dbg 2 Dumping databases...
  dbg 3 Dump command: \$CMD_DUMP\ -u\$1\ -p\$2\ --compact -f 
--all-databases $3
  $CMD_DUMP -u$1 -p$2 --compact -f --all-databases $3 || \
 { err MySQL backup failed!; return 1; }
  return 0;
   }

   backup_packages()
   {
  dbg 3 $LINENO ${FUNCNAME}(): Dumping package list...
  $CMD_DPKG --get-selections
  return $?;
   }

   get_part_string()
   # Return partition string, created from template,
   # in the part=file_to_save; ... format.
   # $1 - template, where %s - partition name (exmpl.: luksbk_%s).
   # $2 - partition list (part_1; part_2; ... ; part_n).
   {
  dbg 3 $LINENO ${FUNCNAME}(): \$1 = \$1\; \$2 = \$2\
  export TEMPL=$1
  local IFS=;
  for i in $2; do
# dbg 3 \$i = $i
 echo $i|awk \
'/.*[^\/]+/ {
   n = split($0, pcomps, /)
   printf(%s=ENVIRON[TEMPL];, $0, pcomps[n]);
}'
  done
  return 0;
   }

   backup_parted_data()
   # $1 - template for the saving LVM backups;
   # $2 - LUKS partition=file_to_save; ... list.
   # Return values:
   # 1 - LVM backup error;
   # 2 - LUKS backup error;
   # 3 - other.
   {
  dbg 2 Dumping partition data...
  # LVM.
  dbg 3 $LINENO ${FUNCNAME}(): Dumping LVM headers

Re: Несколько вопросов вразброс

On Wed, Jul 11, 2012 at 08:35:48PM +0400, Артём Н. wrote:
On 11.07.2012 04:18, Stanislav Maslovski wrote:
Они есть. Этого уже достаточно.
Недостаточно. Достаточно было бы, если бы их на практике было просто
применить... Часто ли это применяется и просто ли?

Применяется в mission-critical systems, насколько часто и насколько
просто - вопрос скорее к тем, кто этими системами плотно занимается.

В таком случае, и сама программная задача тупа в той же мере, в какой
туп ее *полный* тест.

Я - пас :) Желающие продолжить - велкам.

--
Stanislav

Re: Несколько вопросов вразброс

2012-07-10 Пенетрантность Артём Н.

On 08.07.2012 17:23, Stanislav Maslovski wrote:
On Thu, Jul 05, 2012 at 08:20:19PM +0400, Артём Н. wrote:
04.07.2012 09:21, Stanislav Maslovski пишет:
Если система обладает неограниченной памятью, как машина Тьюринга с
бесконечной
лентой, то в общем случае нельзя. На практике нельзя уже при сколько-нибудь
значительном объёме памяти, просто в силу потребного времени.
Я про практику.
На практике ситуация такова: случаев, где возможно *полное* формальное
доказательство правильности программы *больше*, чем случаев, где для этого
достаточно *простых* тестов.
Как правило, построение *полного* теста эквивалентно решению исходной
программной задачи, и, поэтому, не имеет никакой ценности для доказательства.
Понятно. А вообще, случаев, когда:
1. возможно полное доказательство;
2. доказательство имеет практическое значение;
много?

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

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

И на практике: будь всё так хорошо, как вы пишите, все бы уже давно писали
на
Прологе (по крайней мере, знали бы что это такое). :-)
Незнание, как говорится, не освобождает от ответственности. Плюс, в
идеальном мире все бы уже давно писали хотя бы на том же Haskell...
Что такое идеальный мир, в данном случае? o.O
Мир, в котором невежество не выставляется за геройство ;)
Сомнительная утопия или даже антиутопия...

Кстати, а что насчёт Ада?
Пишут (в сегодня почившей вики):
Сторонники Ады утверждают, что единственная альтернатива большому и сложному
языку в больших проектах — это применение нескольких компактных языков,
неизбежно порождающее проблемы с совместимостью, для избавления от которых и
была придумана Ада. Они замечают также, что представление о сложности разработки
на Аде верно лишь отчасти: написание простой программы на Аде действительно
требует больше времени, чем на других, менее формальных языках, типа Си, но
отладка и сопровождение программ, особенно крупных и сложных, значительно
упрощается. По утверждению Стефена Цейгера из Rational Software Corporation[6],
разработка программного обеспечения на Аде в целом обходится на 60 % дешевле, а
разработанная программа имеет в 9 раз меньше дефектов, чем при использовании
языка Си.

Плюс есть GNAT и среда GPS. А от проблем, которые были у старых версий (в т.ч.
совместимостью с др. языками), Ada95, вроде как ушёл... И синтаксис с парадигмой
знакомые... И пишут на нём.
Что про него можете сказать?

Re: Несколько вопросов вразброс

2012-07-10 Пенетрантность Артём Н.

On 05.07.2012 22:04, Artem Chuprina wrote:
Артём Н. - debian-russian@lists.debian.org @ Thu, 05 Jul 2012 19:38:56
+0400:
На практике же основная проблема тестов заключается в том, что они
сами
содержат ошибки и часто тестируют не то, что надо
АН Тесты для тестов... Тесты, в принципе, должны быть просты и
АН малы, как мне кажется.
Тогда они не покроют код.
АН Но это лучше, чем ничего?
Теоретически да. Практически - это сильно зависит от успешности
создания у программиста иллюзии код тестируется.
Но ведь, всё-равно, хоть какой-то тест - лучше, чем отсутствие всякой проверки?

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

Любой статически типизированный функциональный язык с
нормальной
системой типов, начиная с того же Haskell или Ocaml.
АН Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
АН Для него есть какая-то IDE? И как с библиотеками?
Я знаю одну IDE на все случаи жизни. Emacs.
АН И для всяких там GUI? ;-) В общем, я им не пользуюсь.
Ну да. Поскольку мои дизайнерские способности ниже средних,
в отличие
от способностей в разработке поведения, я предпочитаю GUI,
которые
пишут, а не рисуют. Внешний вид - дефолтный, а поведение
описывается
словами.
АН Дык, внешний вид - это не картинка кнопки, а компоновка.
Всё же
АН словами не опишешь. Видеть надо.
Компоновка как раз очень неплохо описывается словами. Заодно
потом не
возникает типичных для мышконавозенного гуя ситуаций, когда при
переводе
на русский половина надписей получается обрезанной, и в лучшем
случае -
поперек, а то я у фотошопа видал, что видно нижнюю половину одной
строки
и верхнюю - другой...
АН Я понимаю, что практически любой интерфейс описывается словами.
:-)
АН Такой же язык. Но создавать его, описывая словами, мне кажется не
АН самой лучшей и перспективной идеей.

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

Ну вот тебе не нравится интерфейс, сделанный на Tk. Внешне. Типа,
gtk'шный круче. С виду.
АН Терпеть его не могу. Стараюсь программы с gtk интерфейсом
АН использовать только когда нет альтернативы. Предпочитаю QT.

Ну, не важно. Пусть qt. По мне ни то, ни другое с виду не лучше Tk
O_O

наблюдаю я сейчас перед собой интерфейсы, сделанные вообще на lucid
(emacs) и на голом xt (xterm), со старательно оторванными менюшками и
скроллбарами, но на вкус и цвет все фломастеры разные.
У вас интернеты не через lynx? o.O

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

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

Зато им будет удобно пользоваться. А от
интерфейса, о чем современные мышевозильцы под давлением маркетологов
обычно забывают, требуется именно удобно себя вести, а не красиво
выглядеть. Иначе непонятно, зачем он вообще нужен - если ты хочешь
красивого, выведи себе xsetroot'ом на весь экран картину Рериха, и
сиди,
наслаждайся...
АН Построение интерфейса не сводится к его описанию.
АН То, как он выглядит, нельзя отделять от того, как он себя ведёт.
АН Красота должна тоже быть.
Красота должна сводиться к удобству. Если шрифт корявый, его неудобно
читать (привет вашей gtk, которая работает через fontconfig, который
подставляет шрифты взамен отсуствующих так, что хочется приговорить его
автора весь остаток жизни смотреть на эти подстановки).
АН Ну, я о таком не знаю. :-)

Если его удобно читать, то он красивый.
АН o.O ЩИТО? Шрифт Mistral, Vladimir Script или Brush Script читать неудобно
АН (причём, не только рукописные, но и большую часть декоративных шрифтов).
АН Тем не менее, он красивый.
Я не согласен с этим утверждением.
Красота - понятие субъективное.

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

Re: Несколько вопросов вразброс

2012-07-10 Пенетрантность Igor Chumak

-Куть
Это если ты делаешь ошибку, которую тест уже ловит. А если ты делаешь
ошибку, которую тест еще не ловит (а она будет, и не одна), то результат
будет тот же самый, как если бы теста не было вообще. Внятная и
подробная диагностика поэтому обязательна.
Я и делаю. Как-раз хотел спросить (очередной провокационный вопрос).
Как организовывать обработку ошибок? :-)
Т.е., вызывается функция. Она должна вернуть код завершения.
В функции м.б. вложенные функции.
В функции может выполниться только часть вызовов вложенных функций.
К примеру, бэкап БД не прошёл, но бэкап состояния пакетов, который
делается
следующим, должен быть сделан.
Какой код возвращать?

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

Можно писать ошибки в глобальный массив, в конце работы его анализировать.

Как сказано было выше, у perl есть use Carp; задачу определить в какой
функции ошибка поможет решить

Re: Несколько вопросов вразброс

2012-07-10 Пенетрантность Stanislav Maslovski

On Tue, Jul 10, 2012 at 09:53:02PM +0400, Артём Н. wrote:
On 08.07.2012 17:23, Stanislav Maslovski wrote:
На практике ситуация такова: случаев, где возможно *полное* формальное
доказательство правильности программы *больше*, чем случаев, где для этого
достаточно *простых* тестов.
Как правило, построение *полного* теста эквивалентно решению исходной
программной задачи, и, поэтому, не имеет никакой ценности для
доказательства.
Понятно. А вообще, случаев, когда:
1. возможно полное доказательство;
2. доказательство имеет практическое значение;
много?

Они есть. Этого уже достаточно.

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

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

Это ещё что за новая сущность? алгоритм доказательства теоремы?

Про доказательство тестами я ничего не писал. :-)

Да ну? А как же пресловутая проверка по всем состояниям?

Кстати, а что насчёт Ада?
[...]
Что про него можете сказать?

Кроме общих мест - ничего.

--
Stanislav

Re: Несколько вопросов вразброс

2012-07-08 Пенетрантность Stanislav Maslovski

On Thu, Jul 05, 2012 at 08:50:05PM +0400, Артём Н. wrote:
Потому что в неимперативных языках нет основной проблемы, которую
решает ООП: разделение общего mutable на множество независимых
mutable. Нет этого самого mutable - нет и проблемы.
Для функциональных понятно...

Уже лучше.

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

Любую модульную систему, в которой модули не прячут состояние внутри
себя и взаимодействуют через stateless protocol и открытые данные.

--
Stanislav

Re: Несколько вопросов вразброс

2012-07-08 Пенетрантность Stanislav Maslovski

On Sat, Jul 07, 2012 at 07:47:33PM +0400, Артём Н. wrote:
05.07.2012 04:53, Stanislav Maslovski пишет:
Я пытаюсь выразить простую мысль, что переход на ООП естественен и
эволюционен _только_ для _императивных_ языков. В функциональных
языках объектная модель смотрится притянутой за уши.
Постепенно понимаю. И, тем не менее, есть языки, которые их пытаются
совмещать?

Есть, но обычно это языки типа Python или Lua, т.е., скриптовые и
*вторичные* (n-ричные) как в смысле заложенных в них идей, так и их
реализации.

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

Это проходит.

--
Stanislav

Re: Несколько вопросов вразброс

2012-07-08 Пенетрантность Stanislav Maslovski

On Thu, Jul 05, 2012 at 08:20:19PM +0400, Артём Н. wrote:
04.07.2012 09:21, Stanislav Maslovski пишет:
Если система обладает неограниченной памятью, как машина Тьюринга с
бесконечной
лентой, то в общем случае нельзя. На практике нельзя уже при сколько-нибудь
значительном объёме памяти, просто в силу потребного времени.
Я про практику.

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

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

Да нет же. Почему - следует из вышенаписанного.

Задолбал! :)

Похоже, что ты сам запутался в своих рассуждениях: тебя *принципиальная*
доказуемость интересует, или всё же доказуемость в частных случаях? С
первым всё ясно, а про второе тебе уже писали, что доказывать во многих
случаях можно, для этого есть методы, и методы эти не основаны на
переборе всех нулей и единиц.
Я неправильно выразился. Полное доказательство корректности достаточно сложной
системы провести на практике невозможно ввиду слишком больших затрат ресурсов
(и
ещё возможно, из-за отсутствия метода доказательства). Так?

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

Вот тебе элементарный пример: докажи теорему Пифагора *тестами* =)

Например, существуют языки программирования, которые вычисляют через
доказательство (через формальную процедуру вывода). PROLOG, например.
На таких языках можно писать программы, которые сами же являются
доказательствами своей правильности.
Да, кстати, Пролог я не понимаю. :-(
Изначально - всё просто. Затем, правила становятся какие-то дикие (к тому
месту,
где начинается рекурсия и прочее). Хотя, может, в книжке было плохо
описано.
Но почему программа является априори правильной?
Я такого не утверждал. Что я утверждал, отквочено выше.
А, кажется понял. :-) Примерно: Программа существует и выдаёт правильные
результаты, значит является правильной?

O_O

Никто не сказал, однако:
Чем ближе язык программирования по синтаксису и семантике к формальному
описанию задачи, тем проще на нем написать верную программу. В случае
пролога, текст программы просто перефразирует исходное условие на языке
логики предикатов. Т.е., программа получается автоматически верной, если
условие задачи было успешно выражено на языке формальной логики и затем
записано в синтаксисе пролога. По сути, это всё, что требуется. Меньше
уже нельзя, без наделения машины интеллектом и знаниями о внешнем мире.
Хм... Но это тоже самое. Просто программа - это описание. И язык здесь -
логика
предикатов. Проверка нужна для описания. Для проверки его соответствия условию
задачи. В сущности, это такая же программа, только перевёрнутая. И,
соответственно, требует проверки. Так?

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

Мир, в котором невежество не выставляется за геройство ;)

--
Stanislav

Re: Несколько вопросов вразброс

2012-07-08 Пенетрантность Артём Н.

On 05.07.2012 20:56, Artem Chuprina wrote:
Артём Н. - debian-russian@lists.debian.org @ Thu, 05 Jul 2012 19:46:36
+0400:
Неверно утверждение, что {} выполним, а строка - нет. И то, и другое
выполнимо, если попросить, и не выполнимо, если не просить. Различие,
собственно, во времени компиляции кода, и это очень существенное
различие.
АН Выполним в плане того, что он трактуется интерпретатором, как код.
АН В случае с eval - трактуется, как строка, со всеми вытекающими.
АН Я это хотел сказать.
Не интерпретатором, а компилятором. Интерпретатор как раз трактует их
одинаково - как код.
Ну да. Просто всё-таки Perl - интерпретируемый... Хотя, кажется он и компилирует
в промежуточный код.

Ну, в общем, да, в открытые перлом ниши со временем придумали и более
удобоподдерживаемые вещи, и более мейнстримные, мать их... Жизнь-то
идет вперед. А вот для написания скриптов с хорошей обработкой ошибок
кроме него да tcl приткнуть и некого. Шелл удобнее для запуска команд,
но плох в обработке ошибок, а всякие питоны и руби слишком многословны
для скриптования.
...
При том, что перл изначально-то был придуман для обработки текста там,
где awk уже оказывался слишком awkward - и в этой нише он по-прежнему
непревзойден.
В общем, всё-таки надо разбираться с Perl. :-|

А может и просто о
словоохотливости автора.
АН Читаю, как много воды.
Не обязательно. Сжатые формальные описания обычно очень трудно понять,
а чтобы описанным пользоваться, нужно наработать интуицию. Это наш мозг
умеет делать только через высокий уровень избыточности. Если автор
хорошо владеет словом, то его более толстая книга может быть усвоена
быстрее.
Хм... Если автор хорошо владеет словом и предметом, он может уместить нужное в
меньший объём. И это будет легко и понятно читаться.

Re: Несколько вопросов вразброс

2012-07-07 Пенетрантность Alexander Galanin

06.07.2012 10:41, Victor Wagner пишет:
On 2012.07.05 at 19:56:29 +0400, Артём Н. wrote:
Понятность среднему хомосапиенсу, как и всякое другое качество, не
бывает бесплатной. И отнюдь не на всех задачах оно важно. Если средний
хомосапиенс не может понять саму задачу, то понятность ему инструмента
для ее решения ценности не имеет.
Хм... И про какие задачи, которые выше понимания среднего, идёт речь? Т.е.
где
сейчас реально используются Пролог системы?

Одна из самых недавних задач, для решения которой использовалась
логическая парадигма, попавшихся мне на глаза, было управление
энергопитанием в Nokia N900. Боковой в свое время этим очень хвастался у
себя в ЖЖ.

http://abbra.livejournal.com/156578.html

Управление энергопитанием в таком девайсе (где одних радиотрактов 4 -
GSM/3G, Wi-Fi, Bluetooth и GPS) это действительно задача, которая выше
понимания среднего homo sapiens.
Честно говоря, я в упор не понимаю причём там Пролог?
В статье описана группировка процессов с использованием виртуализации (что тоже
не очень понятно: если процесс в усыплённой группе задействуется процессом, с
которым работает пользователь: процесс перетаскивают в другую группу или
группа получает тот же приоритет, что и активная? Короче, там мало информации,
много непонятного, да и тема слишком обширная). Ради того, чтобы группам
распределять ресурсы.

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

Кстати, я тут просматривал, ыыы, каменты.
Наткнулся:
http://meego.gitorious.org/maemo-multimedia/policy-settings-basic/trees/master/basic/policy

Хоть какой-то реальный код на Пролог. Покопаться будет любопытно. :-)

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

Когда я смотрел на этот Дракон, бы интузиазм. Но потом у меня сложилось
впечатление, что это типичный графический язык, типа блочных диаграмм.
Попозже (отбирая такты у основного чтения %-) ) ещё почитаю про него.
Сейчас мне непонятно: с какого боку тут Пролог?

Re: Несколько вопросов вразброс

On Sat, 07 Jul 2012 09:49:16 +0400
Артём Н. artio...@yandex.ru wrote:

 Что отсутствие работы с файлами и отсутствие fileevent-ов ещё не говорит о 
 том,
 что ОС не пригодна для использования.

Спасибо, Капитан! :)

  Этим надо озаботиться до выбора инструмента для программирования.
 Чем? Выбором ОС? А, обычно, кто-то спрашивает? :-(

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

-- 
Alexander Galanin


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120707115131.489ffce89eabf1170f601...@galanin.nnov.ru

Re: Несколько вопросов вразброс

2012-07-07 Пенетрантность Alexander Galanin

07.07.2012 11:51, Alexander Galanin пишет:
 On Sat, 07 Jul 2012 09:49:16 +0400
 Артём Н. artio...@yandex.ru wrote:
 
 Что отсутствие работы с файлами и отсутствие fileevent-ов ещё не говорит о 
 том,
 что ОС не пригодна для использования.
 Спасибо, Капитан! :)
Как-бы:
A.N.: Но что делать, если ОС такой функциональности не предоставляет?
Alexander Galanin: Значит не надо использовать ОС, которая не даёт функций для
доступа к файлам и, следовательно, не достойна называться операционной 
системой.
:-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff7f175.1020...@yandex.ru

Re: Несколько вопросов вразброс

On Sat, 07 Jul 2012 12:21:09 +0400
Артём Н. artio...@yandex.ru wrote:

 07.07.2012 11:51, Alexander Galanin пишет:
  On Sat, 07 Jul 2012 09:49:16 +0400
  Артём Н. artio...@yandex.ru wrote:
  
  Что отсутствие работы с файлами и отсутствие fileevent-ов ещё не говорит о 
  том,
  что ОС не пригодна для использования.
  Спасибо, Капитан! :)
 Как-бы:
 A.N.: Но что делать, если ОС такой функциональности не предоставляет?
 Alexander Galanin: Значит не надо использовать ОС, которая не даёт функций для
 доступа к файлам и, следовательно, не достойна называться операционной 
 системой.

Зануда. В том контексте про экзотические вымышленные ОС не говорилось.

-- 
Alexander Galanin


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120707163925.fe2362a55a48032d71a5e...@galanin.nnov.ru

Re: Несколько вопросов вразброс

07.07.2012 16:39, Alexander Galanin пишет:
On Sat, 07 Jul 2012 12:21:09 +0400
Артём Н. artio...@yandex.ru wrote:

07.07.2012 11:51, Alexander Galanin пишет:
On Sat, 07 Jul 2012 09:49:16 +0400
Артём Н. artio...@yandex.ru wrote:

Что отсутствие работы с файлами и отсутствие fileevent-ов ещё не говорит о
том,
что ОС не пригодна для использования.
Спасибо, Капитан! :)
Как-бы:
A.N.: Но что делать, если ОС такой функциональности не предоставляет?
Alexander Galanin: Значит не надо использовать ОС, которая не даёт функций
для
доступа к файлам и, следовательно, не достойна называться операционной
системой.

Зануда.
Просто мне не очень нравится неоднозначность и неточность. В отличие от вас,
видимо. Пойду почитаю на ночь RFC 2119. :-\

В том контексте про экзотические вымышленные ОС не говорилось.
Вы контекст не определили.

экзотические вымышленные ОС
Желаю вам, чтобы одна из вымышленных и экзотических (к примеру, RTEMS)
как-нибудь к вам прилетела, и вы познакомились с ней поближе. ;-)

Re: Несколько вопросов вразброс

05.07.2012 20:57, Artem Chuprina пишет:
 Артём Н. - debian-russian@lists.debian.org  @ Thu, 05 Jul 2012 19:40:27 
 +0400:
 
   -30% производительности -- минимальная цена.
   Про IPC сообщениями? Они пишут, что производительность такая же, как у и 
 прямых
   вызовов.
   Это из известной статьи Таненбаума, где он сам признает, что микроядерная 
 архитектура
   всегда даст среднюю потерю производительности около 30% на 
 intel-совместимых процессорах.
   Он, конечно, уверяет, что это не важно.
  АН Хм... Всё за счёт IPC? Даже, при грамотной организации IPC и узких мест?
 Межпроцессная защита, как и всякая другая защита, бесплатной не бывает.
Это только для микроядерной архитектуры справедливо?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff8551a.7040...@yandex.ru

Re: Несколько вопросов вразброс

06.07.2012 09:53, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Thu, 05 Jul 2012 20:09:51
+0400:

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

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

Все это можно сделать. Увеличение пользы где? Если у тебя
функциональная программа уже есть, то зачем тебе объект в виде
функциональной программы? Чего тебе в языке до введения объектов не
хватало?
АН Хз. Просто я толком не знаю других парадигм. Объект мне кажется
АН достаточно простым и ясным. Например, функция не хранит данные, как
АН объект...
Тоже может. Слово closure (в русском переводе - замыкание) тебе не
встречалось? Нет, функция на C такого не умеет, а на нормальных языках
с функциями - умеют.
Как ни странно, замыкания поддерживает JS. :-) Естественно, встречалось. И
нередко используется.
Но, насколько я понимаю, это получается уже не чистая функция... Не знаю, и не
то это. В объекте привлекает то, что возможно изменять атрибуты... Хотя... Через
замыкания тоже возможно построить классы и объекты (что и делают).
Но, в том же JS, не самый очевидный для понимания типа наследования. На
прототипах. По сравнению с наследованием классов - это сложнее.
У класса - чётко определённый интерфейс, который виден через его описание. И
всегда известно, что будет делать объект. Даже если используется полиморфизм, у
объекта всё-равно есть тип. При прототипном наследовании, кажется, не всё так
однозначно...
И нет такой строгой системы классов. И строгой иерархии тоже нет (хотя и в
языках с наследованием классов, тоже нет иерархии, в общем случае, так что - фиг
его знает)...

Re: Несколько вопросов вразброс

05.07.2012 04:53, Stanislav Maslovski пишет:
Я пытаюсь выразить простую мысль, что переход на ООП естественен и
эволюционен _только_ для _императивных_ языков. В функциональных
языках объектная модель смотрится притянутой за уши.
Постепенно понимаю. И, тем не менее, есть языки, которые их пытаются совмещать?

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

Re: Несколько вопросов вразброс