Эволюция качества ПО

[Alexander Kobets]

Привет!

Правильно ли считать, что эволюция качества ПО в основном определяется
эволюцией языков программирования?

Пока.

[Maxim Kizub]

Mon Jun 06 2005 19:37, Alexander Kobets wrote to All:

AK> Правильно ли считать, что эволюция качества ПО в основном определяется
AK> эволюцией языков программирования?

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

[Serguey Zefirov]

AK>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>> эволюцией языков программирования?
MK> Hет конечно.
MK> Оно определяется (как минимум) всей платформой - язык, рантайм,
MK> стандартные библиотеки.

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

MK> Вообще, выдёргивать из целого одну лишь
MK> часть, и говорить "вот оно, которое главное" - это бесперспективный
MK> подход по определению.

Просто это все так взаимосвязано, что отделить нет возможности.

И язык -- просто удобный показатель.

Yours truly, Serguey Zefirov (thesz AT mail DOT ru)

[Maxim Kizub]

Mon Jun 06 2005 20:07, Serguey Zefirov wrote to Maxim Kizub:

AK>>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>>> эволюцией языков программирования?
MK>> Hет конечно.
MK>> Оно определяется (как минимум) всей платформой - язык, рантайм,
MK>> стандартные библиотеки.

SZ> Вот. И на чем они пишутся? Размер рантайма, качество и удобство
SZ> применения библиотек -- они от языка не зависят?

MK>> Вообще, выдёргивать из целого одну лишь
MK>> часть, и говорить "вот оно, которое главное" - это бесперспективный
MK>> подход по определению.

SZ> Просто это все так взаимосвязано, что отделить нет возможности.

SZ> И язык -- просто удобный показатель.

Hу в общем да, но тогда надо договорится, что такое "язык" :)
Синтаксис - это язык? Вроде да. Hо сказать, что он как-то
уж очень влияет на качество программ - это врядли.
А поддержка exceptions - это язык? Hу можно назвать это языком,
но ведь реально стек раскручивается рантаймом.
Hе было-бы в C printf - скорее всего, и методов с переменным
числом параметров бы не было. А были бы встроенные списки с
map/filter - были бы в С closures & inner methods.

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

[Alexey Simachov]

Здравствуйте Maxim,

Monday, June 6, 2005, 6:43:07 PM, you wrote:

MK> Mon Jun 06 2005 20:07, Serguey Zefirov wrote to Maxim Kizub:

MK> Hу в общем да, но тогда надо договорится, что такое "язык" :)
MK> Синтаксис - это язык? Вроде да. Hо сказать, что он как-то
При изучении языков выделяют три основных аспекта изучения:
1) __синтактика__, изучающая внутренние свойства систем знаков безотносительно к
интерпретации (правила построения знаков в рамках знаковой системы);
2) семантика, рассматривающая отношение знаков к обозначаемому (содержание знаков) или,
что то же, соотношения между знаками и их интерпретациями, независимо от того, кто служит
╚адресатом╩ (интерпретатором);
3) прагматика, исследующая связь знаков с ╚адресатом╩, т. е. проблемы интерпретации знаков
теми, кто их использует, их полезности и ценности для интерпретатора.

[Maxim Kizub]

Mon Jun 06 2005 22:18, Alexey Simachov wrote to Maxim Kizub:

MK>> Hу в общем да, но тогда надо договорится, что такое "язык" :)
MK>> Синтаксис - это язык? Вроде да. Hо сказать, что он как-то

AS> При изучении языков выделяют три основных аспекта изучения:
AS> 1) __синтактика__, изучающая внутренние свойства систем знаков
AS> безотносительно к интерпретации (правила построения знаков в рамках
AS> знаковой системы);
AS> 2) семантика, рассматривающая отношение знаков к обозначаемому
AS> (содержание знаков) или, что то же, соотношения между знаками и их
AS> интерпретациями, независимо от того, кто служит +адресатом=
AS> (интерпретатором);
AS> 3) прагматика, исследующая связь знаков с +адресатом=, т. е. проблемы
AS> интерпретации знаков теми, кто их использует, их полезности и ценности
AS> для интерпретатора.

Лёша, ты правильно задвинул... ещё-б это на русский язык перевести ;)
В смысле - в русло предметной области, сиречь, как эти части
влияют на качество ПО.

Ща попробую перевести.

1) Синтаксис влияет на качество следующим образом - чем компактнее
выражает предметную область программы, тем более прозрачней и
понятней код, тем меньше ошибок и выше качество. В данном случае
я не говорю о компактности в смысле скорости набивания исходников.
Идеальным выбором с этой точки зрения являеются DSL (domain-specific
languages), но задачи, как правило, не описываются одной
областью, а состоят из различных компонент, скажем сетевой обмен
данными, база данных, бизнес-логика и пр. - для каждой из которых
подходит разный DSL. Можно так-же спустится уровнем пониже,
из специализированных областей - то есть туда, где определяются
эти кирпичики (которыми оперируют DSL)... но устраивать флейм
C vs Pascal мы не будем, но скорее всего этот уровень
влияет на качество ПО опосредованно, то есть постольку,
поскольку программист легко читает текст данного языка
(и следовательно делает меньше ошибок)

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

3) Прагматика, это у нас эффективность исполнения программы.
С ней ситуация интересная, в основном тем, что она мифологизирована
до предела. С одной стороны premature optimization is the Evil,
а с другой стороны бесконечные мерянья пипи... ой, бенчмарками.
С одной стороны - программисты дураки, и мы им запретим писать
опасный код (и влепим столько ран-тайм проверок, что оно будет
ползать, а не вычисляться), а с другой стороны рассказываем, что
если к нему прицепить оптимизирующий компилятор, то он на самом
деле ого-го как может быстро (правда, дальше разговоров дело
не идёт).

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

[Vadim Radionov]

Hello sz.

06 июн 05 19:07, Serguey Zefirov wrote to Maxim Kizub:

SZ> Вот. И на чем они пишутся? Размер рантайма, качество и удобство
SZ> применения библиотек -- они от языка не зависят?

Удобство применения скорее не от языка зависит, а от умения воспользоваться
этим
языком. Возьмем к примеру работу с бинарными файлами. Казалось бы, Си идеальный
выбор. Hо мне, например, удобнее Haskell в лице GHC, где полиморфизм позволяет
забыть о размерах типов. Если я, например, в Си пишу в файл следующим образом:

== cut ==
short i16 = 1024;
int i32 = 102000;
float f = 2.17;
double d = 4.11;

char *magic = "MAGIC";

char *str_list[] = { "AAA", "BBBB", "CCCCC" };
unsigned char count = sizeof(str_list)/sizeof(str_list[0]);

FILE *fd = fopen("bin.out","wb");

fwrite(&i16, sizeof(i16), 1, fd);
fwrite(&i32, sizeof(i32), 1, fd);
fwrite(&f, sizeof(f), 1, fd);
fwrite(&d, sizeof(d), 1, fd);

write_string(fd, magic);

write_string_list(fd, str_list, count);

fclose(fd);

== cut ==

То этот же файл в Haskell я читаю единообразно:

== cut ==
readBin :: IO (Int16,Int32,Float,Double,String,[String])
readBin = do
h <- openBinaryFile "bin.out" ReadMode
i16 <- rdBin h
i32 <- rdBin h
f <- rdBin h
d <- rdBin h
s <- rdBin h
sl <- rdBin h
hClose h
return (i16,i32,f,d,s, sl)
== cut ==

Здесь rdBin это моя функция:

class BinReader a where
rdBin :: Handle -> IO a


Для каждого типа я определяю свой rdBin. Для скалярных типов (Int*, Float,
Double) - одна функция. Для строк и списка строк - другая:

instance BinReader Int32 where
rdBin = readCType

instance BinReader Int16 where
rdBin = readCType

instance BinReader Float where
rdBin = readCType

instance BinReader Double where
rdBin = readCType

instance BinReader String where
rdBin = readCString

instance BinReader [String] where
rdBin = readCStringList


Здесь readCType пригодна для чтения любого Storable типа, и определена
следующим
образом:

readCType :: (Storable a) => Handle -> IO a
readCType h = helper undefined
where
helper :: (Storable a) => a -> IO a
helper dummy = do
alloca $ \ptr -> do
hGetBuf h ptr (sizeOf dummy)
peek ptr


Со строками несколько сложнее:

readCString :: Handle -> IO String
readCString h = do
len <- readCType h
readCStringLen $ fromIntegral (len :: Word8)
where
readCStringLen l = do
allocaBytes l $ \ptr -> do
hGetBuf h ptr l
peekCStringLen (ptr,l)


readCStringList :: Handle -> IO [String]
readCStringList h = do
count <- readCType h
sequence $ replicate (fromIntegral (count :: Word8)) $ readCString h



Vadim

[Alexander Kobets]

Hello, World! Hе. Привет Vadim!

Понедельник Июнь 06 2005 20:08, Vadim Radionov писал к ***@uc.ru:
...
VR> Удобство применения скорее не от языка зависит, а от умения
VR> воспользоваться этим языком. Возьмем к примеру работу с бинарными
VR> файлами. Казалось бы, Си идеальный выбор. Hо мне, например, удобнее
VR> Haskell в лице GHC, где полиморфизм позволяет забыть о размерах типов.

Споpно как-то. Понятно что полимоpфизм тебе нpавится, но откуда в С
полимоpфизм? C этой точки зpения он совсем не идеальный, и от умения здесь в
общем-то ничего не зависит. Может быть пpи соответствующем умении пpосто
использовать C++ cout h << x ?

Пока!
Alexander

... Встретимся после короткой 15-минутной рекламы

[Vadim Radionov]

Hello Alexander.

06 июн 05 22:34, you wrote to me:

VR>> Удобство применения скорее не от языка зависит, а от умения
VR>> воспользоваться этим языком. Возьмем к примеру работу с бинарными
VR>> файлами. Казалось бы, Си идеальный выбор. Hо мне, например, удобнее
VR>> Haskell в лице GHC, где полиморфизм позволяет забыть о размерах
VR>> типов.

AK> Споpно как-то. Понятно что полимоpфизм тебе нpавится, но откуда в С
AK> полимоpфизм? C этой точки зpения он совсем не идеальный, и от умения
AK> здесь в общем-то ничего не зависит.

AK> Может быть пpи соответствующем
AK> умении пpосто использовать C++ cout h << x ?

Hе, Чем С++, я лучше буду использовать перловый модуль Convert::BER. ASN
декодер
это возможно то, что более всего мне сейчас подходит для реверс-инженеринга
файла с незнакомым форматом.



Vadim

[Nikita V. Belenki]

Mon Jun 06 2005 20:08, Vadim Radionov wrote to ***@uc.ru:

VR> То этот же файл в Haskell я читаю единообразно:
VR> == cut ==
VR> readBin :: IO (Int16,Int32,Float,Double,String,[String])
VR> readBin = do
VR> h <- openBinaryFile "bin.out" ReadMode
VR> i16 <- rdBin h
VR> i32 <- rdBin h
VR> f <- rdBin h
VR> d <- rdBin h
VR> s <- rdBin h
VR> sl <- rdBin h
VR> hClose h
VR> return (i16,i32,f,d,s, sl)
VR> == cut ==

Плохо. Для того, чтобы убедиться, что ты f и d местами не перепутал, нужно
смотреть сразу в три места: код заголовка, код собственно чтения и код
возврата. Как-нибудь просто это фиксится?

Kit.

[Vadim Radionov]

Hello Nikita.

07 июн 05 14:25, Nikita V. Belenki wrote to me:

VR>> То этот же файл в Haskell я читаю единообразно:
VR>> == cut ==
VR>> readBin :: IO (Int16,Int32,Float,Double,String,[String])
VR>> readBin = do
VR>> h <- openBinaryFile "bin.out" ReadMode
VR>> i16 <- rdBin h
VR>> i32 <- rdBin h
VR>> f <- rdBin h
VR>> d <- rdBin h
VR>> s <- rdBin h
VR>> sl <- rdBin h
VR>> hClose h
VR>> return (i16,i32,f,d,s, sl)
VR>> == cut ==

NVB> Плохо. Для того, чтобы убедиться, что ты f и d местами не перепутал,
NVB> нужно смотреть сразу в три места: код заголовка, код собственно чтения и
NVB> код возврата.

NVB> Как-нибудь просто это фиксится?

Да. ;)

readBin :: IO (Int16,Int32,Float,Double,String,[String])
readBin = do
h <- openBinaryFile "bin.out" ReadMode
r <- rdBin h
hClose h
return r



Для этого тип (,,,,,) тоже должен быть членом класса BinReader, и все типы
компонентов - тоже:


instance (BinReader a, BinReader b, BinReader c, BinReader d,
BinReader e, BinReader f) => BinReader (a,b,c,d,e,f)
where
rdBin h = do
a <- rdBin h
b <- rdBin h
c <- rdBin h
d <- rdBin h
e <- rdBin h
f <- rdBin h
return (a,b,c,d,e,f)



Vadim

[Roman Belenov]

Post by Maxim Kizub
AK> Правильно ли считать, что эволюция качества ПО в основном определяется
AK> эволюцией языков программирования?
Hет конечно.
Оно определяется (как минимум) всей платформой - язык, рантайм,
стандартные библиотеки.

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

[Nikita V. Belenki]

Mon Jun 06 2005 19:37, Alexander Kobets wrote to All:

AK> Правильно ли считать, что эволюция качества ПО в основном определяется
AK> эволюцией языков программирования?

Разве не наоборот?

Kit.

[Maxim Kizub]

Mon Jun 06 2005 20:21, Nikita V. Belenki wrote to Alexander Kobets:

AK>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>> эволюцией языков программирования?

NVB> Разве не наоборот?

Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D

[Alexander Kobets]

Hello, World! Hе. Привет Maxim!

Понедельник Июнь 06 2005 20:44, Maxim Kizub писал к Nikita V. Belenki:
...
NVB>> Разве не наоборот?

MK> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D

Можно пpедположить, что за pазвитием ЯП пpосто не поспевает качество подготовки
пpогpаммистов. Следовательно на качестве ЯП лежит увеличенная ответственность
за воспpиимчивость пpогpаммиста к использованию пpавильных методик
пpогpаммиpования, с помощью данного ЯП.

Пока!
Alexander

... Встретимся после короткой 15-минутной рекламы

[Mikhail Fedotov]

Hi!

MK>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
AK>
AK> Можно пpедположить, что за pазвитием ЯП пpосто не поспевает качество
AK> подготовки пpогpаммистов. Следовательно на качестве ЯП лежит
AK> увеличенная ответственность за воспpиимчивость пpогpаммиста к
AK> использованию пpавильных методик пpогpаммиpования, с помощью данного
AK> ЯП.

(big evil grin, свежи воспоминания от ведения студентам практики по c++)

Mikhail.

[Nikita V. Belenki]

Mon Jun 06 2005 20:44, Maxim Kizub wrote to Nikita V. Belenki:

AK>>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>>> эволюцией языков программирования?
NVB>> Разве не наоборот?
MK> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D

А что, кстати, имеется в виду под "качество ПО деградирует"?

Kit.

[Maxim Kizub]

Tue Jun 07 2005 14:43, Nikita V. Belenki wrote to Maxim Kizub:

AK>>>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>>>> эволюцией языков программирования?
NVB>>> Разве не наоборот?
MK>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D

NVB> А что, кстати, имеется в виду под "качество ПО деградирует"?

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

[Nikita V. Belenki]

Tue Jun 07 2005 14:52, Maxim Kizub wrote to Nikita V. Belenki:

AK>>>>> Правильно ли считать, что эволюция качества ПО в основном
AK>>>>> определяется эволюцией языков программирования?
NVB>>>> Разве не наоборот?
MK>>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
NVB>> А что, кстати, имеется в виду под "качество ПО деградирует"?
MK> Hапример, лет десять назад никто не выпускал бета-версий в продажу.

А это разве не потому, что среднее качество тогдашних релизов было не лучше
среднего качества нынешних бет?

MK> А сейчас это просто повсеместно. Скоро начнут уже альфы продавать,

Hу. А тогдашние альфы не только не были продаваемы, они вообще для
использования были непригодны. Ан масс.

Kit.

[Maxim Kizub]

Tue Jun 07 2005 15:33, Nikita V. Belenki wrote to Maxim Kizub:

NVB> From: "Nikita V. Belenki" <***@kits.net>

NVB> Tue Jun 07 2005 14:52, Maxim Kizub wrote to Nikita V. Belenki:

AK>>>>>> Правильно ли считать, что эволюция качества ПО в основном
AK>>>>>> определяется эволюцией языков программирования?
NVB>>>>> Разве не наоборот?
MK>>>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
NVB>>> А что, кстати, имеется в виду под "качество ПО деградирует"?
MK>> Hапример, лет десять назад никто не выпускал бета-версий в продажу.

NVB> А это разве не потому, что среднее качество тогдашних релизов было не
NVB> лучше среднего качества нынешних бет?

Конечно, когда мы были молодыми, солнышко блестело ярче
и люди были добрее ;) Hо мне все равно кажется, что раньше
с качеством ПО было получше.
Собственно, этому есть простое объяснение - с ростом сложности
программ (функциональности) сложность кода растёт, скажем,
экспоненциально, а реальная отдача - логарифмически.
Hу, тот-же Word. Какая у него была базовая функциональность
на 386 компе, и какая сейчас (и насколько она реально используется),
какая у него была сложность кода, и какая сейчас...
Сейчас программы настолько сложны, что их невозможно протестировать
полностью, только в полевых условиях (то есть непосредственно
пользователями). А _адекватных_ (возросшему уровню сложности
программ) средств контроля за ошибками на стадии проектирования
и сборки кода - всё нет.
Проблемы ошибок решают тупо, в лоб - а вот запретим нахрен
использовать goto, или будем проверять на null & array bounds
везде. Получаем тормоза, не намного более надёжные, но намного
более тормознутые. Грубо говоря, метод имени товарища Прокруста
лечения головной боли методом усечения головы - не работает.
Hо мифы живут.

В общем, проблему надо решать комплексно. Желательно начиная
с железа, и дальше в сторону операционок, языков, рантайма,
библиотек, средств автоматизированной разработки и т.д.
Hо сил такое поднять есть у немногих. Hу, MS, IBM, ещё
две-три компании - и всё. Hо там... в общем, как и в науке,
например. Старый пердун академик, с прошлыми заслугами
и нуль в настоящем времени - принимает решения.
Может в MS и есть люди (почти наверняка есть), которые могли
бы сделать новую платформу, адекватную нынешним задачам.
А сдеали .NET... уважаемые люди делали, но они просто
повторили то, что делали раньше. Так ничего нового этот
.NET и не добавил в программирование, а денег вбухано... :(

[Nikita V. Belenki]

Tue Jun 07 2005 15:56, Maxim Kizub wrote to Nikita V. Belenki:

NVB>>>> А что, кстати, имеется в виду под "качество ПО деградирует"?
MK>>> Hапример, лет десять назад никто не выпускал бета-версий в продажу.
NVB>> А это разве не потому, что среднее качество тогдашних релизов было не
NVB>> лучше среднего качества нынешних бет?
MK> Конечно, когда мы были молодыми, солнышко блестело ярче
MK> и люди были добрее ;) Hо мне все равно кажется, что раньше
MK> с качеством ПО было получше.
MK> Собственно, этому есть простое объяснение - с ростом сложности
MK> программ (функциональности) сложность кода растёт, скажем,
MK> экспоненциально, а реальная отдача - логарифмически.
MK> Hу, тот-же Word. Какая у него была базовая функциональность
MK> на 386 компе, и какая сейчас (и насколько она реально используется),
MK> какая у него была сложность кода, и какая сейчас...

Тем не менее, "Word на 386 компе" падал чуть ли не раз в час, а нынешний -
разве что по большим праздникам.

MK> Сейчас программы настолько сложны, что их невозможно протестировать
MK> полностью, только в полевых условиях (то есть непосредственно
MK> пользователями). А _адекватных_ (возросшему уровню сложности
MK> программ) средств контроля за ошибками на стадии проектирования
MK> и сборки кода - всё нет.

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

MK> Проблемы ошибок решают тупо, в лоб - а вот запретим нахрен
MK> использовать goto, или будем проверять на null & array bounds
MK> везде. Получаем тормоза, не намного более надёжные, но намного
MK> более тормознутые. Грубо говоря, метод имени товарища Прокруста
MK> лечения головной боли методом усечения головы - не работает.
MK> Hо мифы живут.
MK> В общем, проблему надо решать комплексно. Желательно начиная
MK> с железа, и дальше в сторону операционок, языков, рантайма,
MK> библиотек, средств автоматизированной разработки и т.д.

Да. Мифы живут. Мифы про то, что стоит только начать с железа, и проблема
сложности софта куда-то сама собой уйдёт. Казалось бы, эти мифы должны были
быть развеяны ещё Бруксом, ан нет.

MK> Может в MS и есть люди (почти наверняка есть), которые могли
MK> бы сделать новую платформу, адекватную нынешним задачам.
MK> А сдеали .NET... уважаемые люди делали, но они просто
MK> повторили то, что делали раньше. Так ничего нового этот
MK> .NET и не добавил в программирование, а денег вбухано... :(

Это разве деньги? Вот если бы они с железа начали... ;)

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

Kit.

[Maxim Kizub]

Tue Jun 07 2005 16:36, Nikita V. Belenki wrote to Maxim Kizub:

MK>> Hо мифы живут.
MK>> В общем, проблему надо решать комплексно. Желательно начиная
MK>> с железа, и дальше в сторону операционок, языков, рантайма,
MK>> библиотек, средств автоматизированной разработки и т.д.

NVB> Да. Мифы живут. Мифы про то, что стоит только начать с железа, и
NVB> проблема сложности софта куда-то сама собой уйдёт. Казалось бы, эти мифы
NVB> должны были быть развеяны ещё Бруксом, ан нет.

Hе передёргивай. Про то, что они "сами собой" куда-то уйдут
я не говорил. Сапсем наоборот. Hу сделали JVM в железе,
которая тебе и на нуль и на границы массивов проверяет -
и толку? Кто этим пользуется? Или как раньше были лиспы
в железе. Это ведь тоже пусть грубой силы - засунуть
язык в железо, и всё "автоматически" будет хорошо.

Просто нужен взвешенный подход. Без впаданий в крайности.
Достаточно сделать небольшие изменения в железе, чтоб
пропали 90% проблем ОО/функциональных языков.
Достаточно поменять 10% в языке С, чтоб с ним без проблем
могли работать ОО/функциональные языки, без громоздких
прокси и танцев с бубнами. И так далее.

MK>> Может в MS и есть люди (почти наверняка есть), которые могли
MK>> бы сделать новую платформу, адекватную нынешним задачам.
MK>> А сдеали .NET... уважаемые люди делали, но они просто
MK>> повторили то, что делали раньше. Так ничего нового этот
MK>> .NET и не добавил в программирование, а денег вбухано... :(

NVB> Это разве деньги? Вот если бы они с железа начали... ;)

NVB> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными индусами
NVB> - приходится тратить деньги на грамотных. Hаличие возможности
NVB> переполнить буфер рождает червяков и выставляет разработчиков софта в
NVB> крайне дурном свете (просто падение софта при переполнении буфера -
NVB> существенно лучше, поскольку червяков не порождает). И т.п.

Hеверно.
Подход "убрать goto, потому что индусы неграмотные" не работает.
Философию в институте изучал? Hу, марксизм-ленинизм, в купе со
стыренной диалектической? О чём говорит диалектика? О том, что
противоречия между противоположностями (которые те самые, единые
и борющиеся) снимается на _новом_витке_развития_. Убрать или
добавить goto - это не решение. То есть это решение, но имени
тов. Прокруста. Решение а-ля .NET намного лучше - ты можешь
хотя-бы сказать тут я буду делать unsafe код - кто мне верит,
тот может эту программу запускать. Hо он все равно бинарный,
хотя выбор да-нет всё равно лучше отсутствия выбора.

Правильный подход - это новый виток развития. Hапример языки
поддерживающие "прототипирование". То есть ты можешь писать
код расставляя типы переменных, и тогда их компилятор проверит,
или не расставляя, тогда они будут проверены во время
исполнения - получишь что-то вроде скрипта.
Конечно, такие языки ещё достаточно неразвиты, то есть нет
возможности задавать произвольные compile-time checked
constraints. Hо всё равно это уже шаг вперёд. Теперь
представь язык, в котором уровень "надёжности" и соотношение
compile & run time проверок можно задавать произвольно.
Для тех 20% кода, которые критичны по времени - ты устанавливаешь
максимальные настройки оптимизации, и компилятор потребует
везде, где может выскочить null pointer ошибка (или любая
другая run-time ошибка) делать эту проверку вручную или
задавать контракт метода, который бы позволил доказать,
что тут этой ошибки быть не может. Ты получишь 100% надёжность
с минимумом ран-тайм проверок. А в 80% кода, которые
не являются критичными по скорости исполнения, но кушают
80% денег выделенных на проект - ты ставишь другие настройки.
99% ошибок во время исполнения - это ран-тайм ошибки,
типа null pointer, array bounds, type cast, deadlocks
для многотредовых приложений и т.п. Они все прекрасно
поддаются анализу на стадии компиляции, если компилятор
будет иметь достаточно информации в контракте методов.

[Sergey P. Derevyago]

Post by Maxim Kizub
Конечно, когда мы были молодыми, солнышко блестело ярче
и люди были добрее ;)

IMHO не факт ;)

Post by Maxim Kizub
Hо мне все равно кажется, что раньше с качеством ПО было получше.

Ну, с качеством массового ПО для конченых юзеров точно было гораздо лучше,
т.к. писалось оно под DOS, а лимит в 640К заканчивался так быстро, что задача
оптимизации использования ресурсов ставилась с самого начала, а не
откладывалась "на никогда". Эх, Turbo Pascal 5.5, где ты теперь бродишь?...

Post by Maxim Kizub
Проблемы ошибок решают тупо, в лоб - а вот запретим нахрен
использовать goto, или будем проверять на null & array bounds
везде. Получаем тормоза, не намного более надёжные, но намного
более тормознутые. Грубо говоря, метод имени товарища Прокруста
лечения головной боли методом усечения головы - не работает.
Hо мифы живут.

IMHO суть проблемы в том, что они там _все_ проблемы пытаются решать тупо в
лоб. Все начинается с образования:
http://www.c-mentor.ru/articles/show.php?id=12

[Alexander Prudaev]

Hello, Nikita!

07 Июн 05 15:33, Nikita V. Belenki wrote to Maxim Kizub:
AK>>>>>> Правильно ли считать, что эволюция качества ПО в основном
AK>>>>>> определяется эволюцией языков программирования?
NVB>>>>> Разве не наоборот?
MK>>>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
NVB>>> А что, кстати, имеется в виду под "качество ПО деградирует"?
MK>> Hапример, лет десять назад никто не выпускал бета-версий в
MK>> продажу.

NB> А это разве не потому, что среднее качество тогдашних релизов было не
NB> лучше среднего качества нынешних бет?
не. эт потому, что программы были намного проще в том смысле, что
их не нужно было соорганизовывать с другими, местами глючными
программами как то МастДай или напр. DirectrX.

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

а вы считаете, что виндовс вполне пригоден для использования?

Alexander

All around
an eerie sound

[Nikita V. Belenki]

Tue Jun 07 2005 22:06, Alexander Prudaev wrote to Nikita V. Belenki:

AK>>>>>>> Правильно ли считать, что эволюция качества ПО в основном
AK>>>>>>> определяется эволюцией языков программирования?
NVB>>>>>> Разве не наоборот?
MK>>>>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
NVB>>>> А что, кстати, имеется в виду под "качество ПО деградирует"?
MK>>> Hапример, лет десять назад никто не выпускал бета-версий в
MK>>> продажу.
NB>> А это разве не потому, что среднее качество тогдашних релизов было не
NB>> лучше среднего качества нынешних бет?
AP> не. эт потому, что программы были намного проще в том смысле, что
AP> их не нужно было соорганизовывать с другими, местами глючными
AP> программами как то МастДай или напр. DirectrX.

С тем, что они были "проще", никто не спорит. Вопрос в том, были ли они
"качественнее".

MK>>> А сейчас это просто повсеместно. Скоро начнут уже альфы
MK>>> продавать,
NB>> Hу. А тогдашние альфы не только не были продаваемы, они вообще для
NB>> использования были непригодны. Ан масс.
AP> а вы считаете, что виндовс вполне пригоден для использования?

Hу использую же.

Kit.

[Deigris]

Приветствую, Alexander Prudaev.

07 июн 05 21:06 в сообщении к Nikita V. Belenki тобой было написано:

NB>> Hу. А тогдашние альфы не только не были продаваемы, они вообще
NB>> для использования были непригодны. Ан масс.

AP> а вы считаете, что виндовс вполне пригоден для использования?

Он только сейчас и стал (ограниченно) пригоден. "Сейчас" - это с XP (для
некоторых задач - с 2k).

--
До связи! //Дейгрис//

... []

[Maxim Kizub]

Tue Jun 07 2005 22:50, Deigris wrote to Alexander Prudaev:

NB>>> Hу. А тогдашние альфы не только не были продаваемы, они вообще
NB>>> для использования были непригодны. Ан масс.

AP>> а вы считаете, что виндовс вполне пригоден для использования?

D> Он только сейчас и стал (ограниченно) пригоден. "Сейчас" - это с XP (для
D> некоторых задач - с 2k).

Через 5 лет ты скажешь, что и XP не пригоден был.
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

[john gladkih]

Post by Maxim Kizub
NB>>> Hу. А тогдашние альфы не только не были продаваемы, они вообще
NB>>> для использования были непригодны. Ан масс.
AP>> а вы считаете, что виндовс вполне пригоден для использования?
D> Он только сейчас и стал (ограниченно) пригоден. "Сейчас" - это с XP (для
D> некоторых задач - с 2k).
Через 5 лет ты скажешь, что и XP не пригоден был.
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

бедные задолбаное писюками pepsi generation. цивилизованный мир
использовал 32х битные системы до появления этих 16битных
уродливых калькуляроров-переростков. причем даже сегодня эти
уродцы не достигли и 30% процентов надежности тех старых
систем. а цивилизованный мир продолжает смеяться уже с десяток
лет использую 64хбитные системы

[Maxim Kizub]

Post by Maxim Kizub
NB>>> Hу. А тогдашние альфы не только не были продаваемы, они вообще
NB>>> для использования были непригодны. Ан масс.
AP>> а вы считаете, что виндовс вполне пригоден для использования?
D> Он только сейчас и стал (ограниченно) пригоден. "Сейчас" - это с XP
(для
D> некоторых задач - с 2k).
Через 5 лет ты скажешь, что и XP не пригоден был.
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg> использовал 32х битные системы до появления этих 16битных
jg> уродливых калькуляроров-переростков. причем даже сегодня эти
jg> уродцы не достигли и 30% процентов надежности тех старых
jg> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg> лет использую 64хбитные системы

Вань, ты или дурак или хамло. Скорее и то и другое вместе.

[Valentin Nechayev]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>> использовал 32х битные системы до появления этих 16битных
jg>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>> уродцы не достигли и 30% процентов надежности тех старых
jg>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>> лет использую 64хбитные системы
MK> Вань, ты или дурак или хамло. Скорее и то и другое вместе.

А я с ним согласен. Я тоже дурак и хамло?


-netch-

[Serhiy Storchaka]

Post by Valentin Nechayev

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>> использовал 32х битные системы до появления этих 16битных
jg>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>> уродцы не достигли и 30% процентов надежности тех старых
jg>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>> лет использую 64хбитные системы
MK> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
А я с ним согласен. Я тоже дурак и хамло?

По поводу "бедныого задолбаного писюками pepsi generation"?

Я вот вспоминаю, насколько вырос мир при пересаживании с 16-битных
БК-0010Ш (трижды кастрированный PDP-11) на 8-битные Ямахи и Корветы. А
вы говорит 32 бит.

[Valentin Nechayev]

jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>> использовал 32х битные системы до появления этих 16битных
jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>> лет использую 64хбитные системы
MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.

Post by Valentin Nechayev
А я с ним согласен. Я тоже дурак и хамло?

SS> По поводу "бедныого задолбаного писюками pepsi generation"?
И про это тоже. Надо же ещё что-то видеть вокруг.

SS> Я вот вспоминаю, насколько вырос мир при пересаживании с 16-битных
SS> БК-0010Ш (трижды кастрированный PDP-11) на 8-битные Ямахи и Корветы. А
SS> вы говорит 32 бит.

Куда он вырос-то?


-netch-

[Aleksey Cheusov]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>> использовал 32х битные системы до появления этих 16битных
jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>> лет использую 64хбитные системы
MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.

VN> А я с ним согласен. Я тоже дурак и хамло?

Его, и твоя стало быть тоже, позиция абсолютно неконструктивна.
За последние 20 лет произошло великое событие.
Всеобщая компьютеризация называется, теперь у каждого
дятла на столе стоит новый инструмент, которого не могло быть раньше,
и который принес ему и миру в целом очень много полезного.
Я не большой поклонник винды, и всяких переразвитых 8080,
но именно IBM, Microsoft и Intel сделали эту революцию.
Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
никакого отношения.
Если бы отказались вовремя от своего снобизма
и вели бизнес умнее, вот такого бы не писали
http://www.apple.com/pr/library/2005/jun/06intel.html
И несвоевременно 64-битные Alphы бы не сдыхали.

[Valentin Nechayev]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>>> использовал 32х битные системы до появления этих 16битных
jg>>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>>> лет использую 64хбитные системы
MK>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>> А я с ним согласен. Я тоже дурак и хамло?
AC> Его, и твоя стало быть тоже, позиция абсолютно неконструктивна.
AC> За последние 20 лет произошло великое событие.
AC> Всеобщая компьютеризация называется, теперь у каждого
AC> дятла на столе стоит новый инструмент, которого не могло быть раньше,
AC> и который принес ему и миру в целом очень много полезного.
AC> Я не большой поклонник винды, и всяких переразвитых 8080,
AC> но именно IBM, Microsoft и Intel сделали эту революцию.

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

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

AC> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC> никакого отношения.

Имеют. Они в этом активно участвовали.


-netch-

[Aleksey Cheusov]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>>>> использовал 32х битные системы до появления этих 16битных
jg>>>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>>>> лет использую 64хбитные системы
MK>>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>>> А я с ним согласен. Я тоже дурак и хамло?
AC>> Его, и твоя стало быть тоже, позиция абсолютно неконструктивна.
AC>> За последние 20 лет произошло великое событие.
AC>> Всеобщая компьютеризация называется, теперь у каждого
AC>> дятла на столе стоит новый инструмент, которого не могло быть раньше,
AC>> и который принес ему и миру в целом очень много полезного.
AC>> Я не большой поклонник винды, и всяких переразвитых 8080,
AC>> но именно IBM, Microsoft и Intel сделали эту революцию.

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

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

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

AC>> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC>> никакого отношения.

VN> Имеют. Они в этом активно участвовали.

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

[Maxim Kizub]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>>>> использовал 32х битные системы до появления этих 16битных
jg>>>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>>>> лет использую 64хбитные системы
MK>>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>>> А я с ним согласен. Я тоже дурак и хамло?
AC>> Его, и твоя стало быть тоже, позиция абсолютно неконструктивна.
AC>> За последние 20 лет произошло великое событие.
AC>> Всеобщая компьютеризация называется, теперь у каждого
AC>> дятла на столе стоит новый инструмент, которого не могло быть раньше,
AC>> и который принес ему и миру в целом очень много полезного.
AC>> Я не большой поклонник винды, и всяких переразвитых 8080,
AC>> но именно IBM, Microsoft и Intel сделали эту революцию.

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

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

AC>> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC>> никакого отношения.

VN> Имеют. Они в этом активно участвовали.

Эти разговоры о корявости и прямости просто смешны.
Какая разницы - корявое оно на 50% или на 60%?
Всё равно корявое.

[Alexander Krotov]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>> использовал 32х битные системы до появления этих 16битных
jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>> лет использую 64хбитные системы
MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>
VN> А я с ним согласен. Я тоже дурак и хамло?

Кстати, а кто из присутствующих дураков и хамиов реально воюет с
64битными ситсемами ? ;-)

Каждый раз, когда как дурак побъюсь с возникающими с ними
проблемами временно превращаюсь в хама.

-ank http://www.finnov.net/~ank

[john gladkih]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>> использовал 32х битные системы до появления этих 16битных
jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>> лет использую 64хбитные системы
MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>
VN> А я с ним согласен. Я тоже дурак и хамло?
Кстати, а кто из присутствующих дураков и хамиов реально воюет с
64битными ситсемами ? ;-)

а что с ними бороться? недавно заклинило что тесты со странным
сигналами на дебильном винтеле падают - оказывается писал дома и
по недогляду хапал 38G памяти. ну кто бы подумал что для винтеля
это смертельный размер... ну а поскольку еще и freebsd 4 это
было то вообще песТня ;)

Каждый раз, когда как дурак побъюсь с возникающими с ними

ы?

проблемами временно превращаюсь в хама.

[Alexander Krotov]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>> использовал 32х битные системы до появления этих 16битных
jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>> лет использую 64хбитные системы
MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>
VN> А я с ним согласен. Я тоже дурак и хамло?
Кстати, а кто из присутствующих дураков и хамиов реально воюет с
64битными ситсемами ? ;-)

jg>
jg> а что с ними бороться? недавно заклинило что тесты со странным
jg> сигналами на дебильном винтеле падают - оказывается писал дома и
jg> по недогляду хапал 38G памяти. ну кто бы подумал что для винтеля
jg> это смертельный размер... ну а поскольку еще и freebsd 4 это
jg> было то вообще песТня ;)
jg>

Каждый раз, когда как дурак побъюсь с возникающими с ними

jg>
jg> ы?

Вот Нечаев меня иногда лучше понимает, чем я сам себя ;-)

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

Или операционка упадет в корку при совсем безобидных
действиях (что частенько проделывает FreeBSD, не только 4ая,
я на amd64 только пятую использовал), то компилятор сгенерирует
какую-нибудь дурь (под итаниум), то он же откажется следовать
ядреным соглашениям о вызовах (солярис, при написании ядреного модуля),
то приложения норовят через int указатели прогнать, то сервер
версии k.l.m вполне работает, а после заделывания очередной
дырки версия k.l.m+1 забывает о своем трудовом прошлом и
работать отказывается..

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

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

Свежачек-с прошлонедельный: hpux 64битный. При установке руками
времени (stime(2)) срабатывают (самым разнообразным образом) сисколы,
для которых важны таймауты. За 32битным такого замечено небыло.

Вот и инетересно, о каких же системых ты говорил ?

-ank http://www.finnov.net/~ank

[john gladkih]

Post by Alexander Krotov
Свежачек-с прошлонедельный: hpux 64битный. При установке
руками
времени (stime(2)) срабатывают (самым разнообразным образом) сисколы,
для которых важны таймауты. За 32битным такого замечено
небыло.

жуть какая :) вобщем-то stime() штука такая. нужно
мееееееедленно двигать ;)

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

Post by Alexander Krotov
Вот и инетересно, о каких же системых ты говорил ?

сейчас дома на амд64 гоняю Debian/sid, никаких проблем -
ну совершенно никаких. даже лениво как-то фрю 5ю сюда водружать,
ну совсем ленивый стал. так под ним и пишу. все удобнее
недоделки фряхи. совсем она стала никуда не годная. а под
четверкой компайлеры старые, соберешь новый - останешся совсем
без возможности покапаться gdb. не сильно нужно, но иногда
приходится.

то что гореписатели из клана OSS любят указатели в int загонять,
так это у них дефекты в ДНК :) что с них взять. они вон в
соседней эхе все страдают и вспоминают золотые времена 640k
should be enough ;) pepsi inside generation испорченное
винтелем и с кругозором соответствующим... :(

[Alexander Krotov]

Post by Alexander Krotov
Свежачек-с прошлонедельный: hpux 64битный. При установке
руками
времени (stime(2)) срабатывают (самым разнообразным образом) сисколы,
для которых важны таймауты. За 32битным такого замечено
небыло.

jg>
jg> жуть какая :) вобщем-то stime() штука такая. нужно
jg> мееееееедленно двигать ;)

А собственно двигаю за stime там не я. Я бы его вообще не трогал ;-)
но тестов пришлось понаписать.

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

jg> слава Богу давно уже не приходится с ним возиться. вещь в
jg> себе. он у тебя случайно не для итаника? ;) хочется послушать
jg> отзывы об этом чуде.

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

Post by Alexander Krotov
Вот и инетересно, о каких же системых ты говорил ?

jg>
jg> сейчас дома на амд64 гоняю Debian/sid, никаких проблем -
jg> ну совершенно никаких. даже лениво как-то фрю 5ю сюда водружать,
jg> ну совсем ленивый стал. так под ним и пишу. все удобнее
jg> недоделки фряхи. совсем она стала никуда не годная. а под
jg> четверкой компайлеры старые, соберешь новый - останешся совсем
jg> без возможности покапаться gdb. не сильно нужно, но иногда
jg> приходится.

С Debian мне давно ничего не приходилось делать.

А 5ая стоит на основном рабочем десктопе (32) и менять ее ни
на что не собираюсь - она меня любит, я ее тоже уважаю.

-ank http://www.finnov.net/~ank

[john gladkih]

Post by Alexander Krotov

Post by Alexander Krotov
Свежачек-с прошлонедельный: hpux 64битный. При установке
руками
времени (stime(2)) срабатывают (самым разнообразным образом) сисколы,
для которых важны таймауты. За 32битным такого замечено
небыло.

jg>
jg> жуть какая :) вобщем-то stime() штука такая. нужно
jg> мееееееедленно двигать ;)
А собственно двигаю за stime там не я. Я бы его вообще не трогал ;-)
но тестов пришлось понаписать.
И там его как ни двигай - везде косяки. Все-равно таймауты срабатывают
самым разнообразным образом. Сказали ждать полсекунды - ждет, сказали
ждать две секунды - срабатывает. В одну сторону двинешь - сработают,
в другую - не сработают. А мне, собственно, даже не важно сработают
или нет, важно, чтобы вели себя одинаково, и, желательно, срабатывали
по-порядку.

жуть полнейшая :)

Post by Alexander Krotov
jg> слава Богу давно уже не приходится с ним возиться. вещь в
jg> себе. он у тебя случайно не для итаника? ;) хочется послушать
jg> отзывы об этом чуде.
С hpux под i2 тоже возился. Из совсем косяков там только
весьма глючный компилятор (давно такого не видал), но в-целом
система не хуже других. (То есть работоспособная, но ни особой
производительности, ни безпроблемности от нее ожидать не
стоит).

Oracle уже бегает? ;)

Post by Alexander Krotov

Post by Alexander Krotov
Вот и инетересно, о каких же системых ты говорил ?

jg>
jg> сейчас дома на амд64 гоняю Debian/sid, никаких проблем -
jg> ну совершенно никаких. даже лениво как-то фрю 5ю сюда водружать,
jg> ну совсем ленивый стал. так под ним и пишу. все удобнее
jg> недоделки фряхи. совсем она стала никуда не годная. а под
jg> четверкой компайлеры старые, соберешь новый - останешся совсем
jg> без возможности покапаться gdb. не сильно нужно, но иногда
jg> приходится.
С Debian мне давно ничего не приходилось делать.
А 5ая стоит на основном рабочем десктопе (32) и менять ее ни
на что не собираюсь - она меня любит, я ее тоже уважаю.

ну 32 это совсем не интересно. делал тут апгрейд 5.2 на 5.4, вот
это секс так секс. давно такого не было. source отказался, пошел
делать через 5.3. этот этап не обругался что не умеет но и
собраться 5.3 старым компайлером не смогла. стал делать binary
5.2 -> 5.4 - разнесло все :) больше ничего на ней не
откомпилировать, что-то с crt поломалось. tls_init или что-то
типа того не находится. так и придется ей format c: делать :(

[Alexander Krotov]

john gladkih <***@kak-sam.to> wrote:
jg> жуть полнейшая :)

Да не говори ;-)

Post by Alexander Krotov
jg> слава Богу давно уже не приходится с ним возиться. вещь в
jg> себе. он у тебя случайно не для итаника? ;) хочется послушать
jg> отзывы об этом чуде.
С hpux под i2 тоже возился. Из совсем косяков там только
весьма глючный компилятор (давно такого не видал), но в-целом
система не хуже других. (То есть работоспособная, но ни особой
производительности, ни безпроблемности от нее ожидать не
стоит).

jg>
jg> Oracle уже бегает? ;)

Никому не советую стоять на пути бегущего Оракла ;-(

Мы тоже бегали, пока вдруг не.

jg> ну 32 это совсем не интересно. делал тут апгрейд 5.2 на 5.4, вот
jg> это секс так секс. давно такого не было. source отказался, пошел
jg> делать через 5.3. этот этап не обругался что не умеет но и
jg> собраться 5.3 старым компайлером не смогла. стал делать binary
jg> 5.2 -> 5.4 - разнесло все :) больше ничего на ней не
jg> откомпилировать, что-то с crt поломалось. tls_init или что-то
jg> типа того не находится. так и придется ей format c: делать :(

Вот где жуть ;-)

-ank http://www.finnov.net/~ank

[Dmitry Subbotin]

Wed Jun 15 2005 17:17, Alexander Krotov wrote to john gladkih:

AK> то приложения норовят через int указатели прогнать

Люди, а почему прогонять указатели через int на 64битных платформах чревато?
Ведь, казалось бы, и то и другое одного размера, что мешает совать их друг в
друга?
Я правда не очень понимаю зачем это делать, но это уже другой вопрос. :)

Дмитрий

[Alex Besogonov]

Post by Dmitry Subbotin
AK> то приложения норовят через int указатели прогнать
Люди, а почему прогонять указатели через int на 64битных платформах чревато?
Ведь, казалось бы, и то и другое одного размера, что мешает совать их друг в
друга?

Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
платформ со стандартными настройками компилятора.

[Dmitry Subbotin]

Post by Dmitry Subbotin
Люди, а почему прогонять указатели через int на 64битных платформах
чревато? Ведь, казалось бы, и то и другое одного размера, что мешает
совать их друг в друга?

AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
AB> платформ со стандартными настройками компилятора.

Так надо изменить эти настройки и радоваться жизни. :-)

Дмитрий

[Alex Besogonov]

Post by Dmitry Subbotin

Post by Dmitry Subbotin
Люди, а почему прогонять указатели через int на 64битных платформах
чревато? Ведь, казалось бы, и то и другое одного размера, что мешает
совать их друг в друга?

AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
AB> платформ со стандартными настройками компилятора.
Так надо изменить эти настройки и радоваться жизни. :-)

Ты думаешь зря эти настройки сделали такими?

[Dmitry Subbotin]

Post by Dmitry Subbotin
AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
AB> платформ со стандартными настройками компилятора.
Так надо изменить эти настройки и радоваться жизни. :-)

AB> Ты думаешь зря эти настройки сделали такими?

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

Дмитрий

[Alex Besogonov]

Post by Dmitry Subbotin

Post by Dmitry Subbotin
AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
AB> платформ со стандартными настройками компилятора.
Так надо изменить эти настройки и радоваться жизни. :-)

AB> Ты думаешь зря эти настройки сделали такими?
Я думаю такие настройки сделаны для экономии памяти. Ну а почему бы не забить
на память для какой-нибудь не очень жручей программы? Хотя радоваться жизни
наверное не получится - будет конфликт со всеми библиотеками...

Просто даже 64-битные процессоры часто могут более оптимально работать с
32-битными велечинами, да и нечасто нужны 64 бита для реальных величин.

[Valentin Nechayev]

MK>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>> А я с ним согласен. Я тоже дурак и хамло?
AK> Кстати, а кто из присутствующих дураков и хамиов реально воюет с
AK> 64битными ситсемами ? ;-)

Есть в боевой эксплуатации альфа - сойдёт?
Я тебе, кажется, даже вживую рассказывал приколы с ней - что mysql & postgres
начали нормально работать на таких системах только где-то с конца 2000-го,
до того один вообще не собирался, другой пёк корку на старте.

AK> Каждый раз, когда как дурак побъюсь с возникающими с ними
AK> проблемами временно превращаюсь в хама.

Опять бьём тех кто запихивает void* в int, как автор одного почтенного MTA?


-netch-

[Maxim Kizub]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>> использовал 32х битные системы до появления этих 16битных
jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>> лет использую 64хбитные системы
MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.

VN> А я с ним согласен. Я тоже дурак и хамло?

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

[Valentin Nechayev]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>>> использовал 32х битные системы до появления этих 16битных
jg>>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>>> лет использую 64хбитные системы
MK>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>> А я с ним согласен. Я тоже дурак и хамло?
MK> Hу ты же вежливо... значит не хамло. Hо если согласен с ним -
MK> выкинь мобилку, тогда я тебе поверю, что ты с ним согласен.

Зачем выкидывать? Я даже модем выкидывать не буду, несмотря на то, что там
процессор - embedded клон 8-битного 6502. Всему своё место. Просто надо
что-то видеть и кроме попсы для пипла. (Это не тебе в наезд, это его
производителям в наезд.)


-netch-

[Maxim Kizub]

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>>>> использовал 32х битные системы до появления этих 16битных
jg>>>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>>>> лет использую 64хбитные системы
MK>>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>>> А я с ним согласен. Я тоже дурак и хамло?
MK>> Hу ты же вежливо... значит не хамло. Hо если согласен с ним -
MK>> выкинь мобилку, тогда я тебе поверю, что ты с ним согласен.

VN> Зачем выкидывать? Я даже модем выкидывать не буду, несмотря на то, что
VN> там процессор - embedded клон 8-битного 6502. Всему своё место. Просто
VN> надо что-то видеть и кроме попсы для пипла.

Звыняйте, но я пасую перед твоей логикой. Если всему своё место -
то каким боком ты с Ваней согласен? В плане, что лучше
быть здоровым и богатым, чем бедным и больным? Так с этим все
согласны. Hо Ванюша ведь не об этом, он о своём снобизме.

[john gladkih]

Post by Aleksey Cheusov

Post by Maxim Kizub
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg>>>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>>>> использовал 32х битные системы до появления этих 16битных
jg>>>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>>>> лет использую 64хбитные системы
MK>>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>>> А я с ним согласен. Я тоже дурак и хамло?
MK>> Hу ты же вежливо... значит не хамло. Hо если согласен с ним -
MK>> выкинь мобилку, тогда я тебе поверю, что ты с ним согласен.
VN> Зачем выкидывать? Я даже модем выкидывать не буду, несмотря на то, что
VN> там процессор - embedded клон 8-битного 6502. Всему своё место. Просто
VN> надо что-то видеть и кроме попсы для пипла.
Звыняйте, но я пасую перед твоей логикой. Если всему своё место -
то каким боком ты с Ваней согласен? В плане, что лучше
быть здоровым и богатым, чем бедным и больным? Так с этим все
согласны. Hо Ванюша ведь не об этом, он о своём снобизме.

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

[john gladkih]

Post by Maxim Kizub

Post by Maxim Kizub
NB>>> Hу. А тогдашние альфы не только не были продаваемы, они вообще
NB>>> для использования были непригодны. Ан масс.
AP>> а вы считаете, что виндовс вполне пригоден для использования?
D> Он только сейчас и стал (ограниченно) пригоден. "Сейчас" - это с XP
(для
D> некоторых задач - с 2k).
Через 5 лет ты скажешь, что и XP не пригоден был.
А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
на 4 мега...

jg> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg> использовал 32х битные системы до появления этих 16битных
jg> уродливых калькуляроров-переростков. причем даже сегодня эти
jg> уродцы не достигли и 30% процентов надежности тех старых
jg> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg> лет использую 64хбитные системы
Вань, ты или дурак или хамло. Скорее и то и другое вместе.

цивилизованный мир продолжает смеяться над pepsi
generation. факт. он никогда не знал уродства 640k should be
enough.

[Serhiy Storchaka]

Post by john gladkih
цивилизованный мир продолжает смеяться над pepsi
generation. факт. он никогда не знал уродства 640k should be
enough.

64k should be enough. Ну как можно написать программу больше чем из
10000 команд?

[john gladkih]

Post by Serhiy Storchaka

Post by john gladkih
цивилизованный мир продолжает смеяться над pepsi
generation. факт. он никогда не знал уродства 640k should be
enough.

64k should be enough. Ну как можно написать программу больше чем из
10000 команд?

у каждого свой замкнутый блок

[john gladkih]

Post by Serguey Zefirov
AK>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>> эволюцией языков программирования?
NVB> Разве не наоборот?
Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D

в которую сторону эволюционируют? можно привести пример
прогресса за последние 10 лет?

[Maxim Kizub]

Post by Serguey Zefirov
AK>> Правильно ли считать, что эволюция качества ПО в основном
определяется
AK>> эволюцией языков программирования?
NVB> Разве не наоборот?
Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D

jg> в которую сторону эволюционируют? можно привести пример
jg> прогресса за последние 10 лет?

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

[john gladkih]

Post by Maxim Kizub

Post by Serguey Zefirov
AK>> Правильно ли считать, что эволюция качества ПО в основном
определяется
AK>> эволюцией языков программирования?
NVB> Разве не наоборот?
Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D

jg> в которую сторону эволюционируют? можно привести пример
jg> прогресса за последние 10 лет?
Тебе в какой области - технологической или теоретической?
Теория ядерного распада и связи энергии с массой была
изобретена вначале века - это теоретическая область, в ней
есть что-то новое, но его можно с лёгкостью обозвать бесполезным.
Изготовление ядерной бомбы и электростанций произошло в середине
века, это технологическая область - в ней как-бы нет ничего
принципиально нового.
Я думаю, что ты не видишь прогресса по этим причинам -
принципиально новое для тебя бесполезно и ты его не
замечаешь, а технологически новое ты не признаешь за прогресс,
так как в нём ничего нового для тебя нет.

ну пургу ты гнать мастер. а если посуществу вопроcа а не по
процедуре?

[Alexander Kobets]

Hello, World! Hе. Привет Nikita!

Понедельник Июнь 06 2005 20:21, Nikita V. Belenki писал к Alexander Kobets:
AK>> Правильно ли считать, что эволюция качества ПО в основном
AK>> определяется эволюцией языков программирования?

NB> Разве не наоборот?

Возможно, и языки эволюциониpут в соответствии с новым ПО, но я думаю - только
концептуально. Вообще конечно, и то и дpугое качественно pазвивается, поэтому
можно усмотpеть некотоpые взаимосвязи.

Пока!
Alexander

... Встретимся после короткой 15-минутной рекламы

[Oleg Polyanski]

Post by Alexander Kobets
Правильно ли считать, что эволюция качества ПО в основном определяется
эволюцией языков программирования?

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

Oleg

[Maxim Kizub]

Tue Jun 07 2005 23:19, Serguey Zefirov wrote to Maxim Kizub:

MK>> Короче. Гы-гы.
MK>> Если у кого-то есть несколько лишних лимонов денег (а не рублей),
MK>> то за пару лет я вам сделаю нормальную платформу программирования,
MK>> на порядок превосходящую имеющиеся на нынешний момент мэйнстримы.
MK>> Hо увы, пока ни у кого этих денег не нашлось...

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

Hе, ну я же в смысле сметы, а не в смысле что сам накодирую :D
Hу и "пара лет" - это в смысле демо-версии, на которой
уже можно пускать бенчмарки, но не что-то реальное. А под
бенчмарки и прочие крики о крутости - уже занимать у
банков или на бирже реальные деньги, то есть десятки лимонов...
Это же работа сравнимая с написанием c++/java/.net и пр. -
за пару лет лаборатория может выдать на гора продукт,
который уже раскручивается маркетологами долгие годы...
Опять же тактика и стратегия - например, на PC лезть сразу не лезть,
лучше где-нибудь на мобилках начать - там и так зоопарк
железа и софта, и тиражи приличные. Когда технология
уже будет более отработана (что лет пять, минимум) - тогда
уже на персоналки и сервера можно.

[Serguey Zefirov]

SZ>> Как ты сам понимаешь, если ты ее будешь делать на чем-то привычном, то
SZ>> как мы сможем проверить эту платформу? Если же ты будешь ее делать на
SZ>> ней же самой, то, получается, стоимость работы программиста для этой
SZ>> платформы превышает один миллион денег в год (несколько -- это
SZ>> обязательно больше двух).
MK> Hе, ну я же в смысле сметы, а не в смысле что сам накодирую :D
MK> Hу и "пара лет" - это в смысле демо-версии, на которой
MK> уже можно пускать бенчмарки, но не что-то реальное. А под
MK> бенчмарки и прочие крики о крутости - уже занимать у
MK> банков или на бирже реальные деньги, то есть десятки лимонов...
MK> Это же работа сравнимая с написанием c++/java/.net и пр. -
MK> за пару лет лаборатория может выдать на гора продукт,
MK> который уже раскручивается маркетологами долгие годы...
MK> [....] Когда технология
MK> уже будет более отработана (что лет пять, минимум) - тогда
MK> уже на персоналки и сервера можно.

Что-то опять плохо выходит. ;)

Что ты планируешь отрабатывать "лет пять" и чем это будет отличаться от
современных технологий, которым тоже надо сравнимое время (.Net как раз и
имеет возраст лет в пять)?

Hо это я уже так, к словам придраться... ;)

Yours truly, Serguey Zefirov (thesz AT mail DOT ru)

[Maxim Kizub]

Wed Jun 08 2005 10:30, Serguey Zefirov wrote to Maxim Kizub:

SZ>>> Как ты сам понимаешь, если ты ее будешь делать на чем-то привычном, то
SZ>>> как мы сможем проверить эту платформу? Если же ты будешь ее делать на
SZ>>> ней же самой, то, получается, стоимость работы программиста для этой
SZ>>> платформы превышает один миллион денег в год (несколько -- это
SZ>>> обязательно больше двух).
MK>> Hе, ну я же в смысле сметы, а не в смысле что сам накодирую :D
MK>> Hу и "пара лет" - это в смысле демо-версии, на которой
MK>> уже можно пускать бенчмарки, но не что-то реальное. А под
MK>> бенчмарки и прочие крики о крутости - уже занимать у
MK>> банков или на бирже реальные деньги, то есть десятки лимонов...
MK>> Это же работа сравнимая с написанием c++/java/.net и пр. -
MK>> за пару лет лаборатория может выдать на гора продукт,
MK>> который уже раскручивается маркетологами долгие годы...
MK>> [....] Когда технология
MK>> уже будет более отработана (что лет пять, минимум) - тогда
MK>> уже на персоналки и сервера можно.

SZ> Что-то опять плохо выходит. ;)

SZ> Что ты планируешь отрабатывать "лет пять" и чем это будет отличаться от
SZ> современных технологий, которым тоже надо сравнимое время (.Net как раз и
SZ> имеет возраст лет в пять)?

Hу я тут писал кой-чего, это по отношению к Java.

1. Если будет возможность сделать изменения железа
- тегирование примитивных типов данных (9-й бит в байте),
работа с тегами и аппаратная верификация операций
по тегам
- аппаратная поддержка GC (не GC реализованный в железе, а
именно поддержка, за счет тегированых данных, поддержка
read/write барьеров и пр.)
- аппаратная поддержка компактного кода (фактически
интерпретаторов, что позволит раза в 3 уменьшит размер
редко исполняемого кода), возможно с использованием
тегов примитивных данных
Возможно ещё кой-какие улучшения поддержки ОО языков
(типа специальных регистров контекста, то есть для this,
и пр.)

2. Рантайм (VM)
- поддержка unsafe инструкций, вплоть до target ассемблера
- больший набор базовых операций (ротация битов, unsigned
арифметика, операции с упакованными в битовые поля данными
и пр.)
- поддержка структур, union, tuple, размещение их в
heap, стеке, массивах и пр.
- тегированные 1 словом в заголовке сложные данные (структуры
и т.д.), убрать из базового класса Object все методы
и данные
- поддержка как GC, так и ручного управления выделенной
памятью, разные типы памяти (с cpmpaction и без, со сборкой
мусора и без, read-only и read-write и так далее)
- поддержка указателей и их арифметики
- верификация и компиляция как на target устройстве, так и
на host (server), в том числе и частично на host и частично
на target
- отделение типа данных от класса, параметризированные типы;
класс описывает структуру данных, тип - это набор
constraints - параметры класса, класс памяти (immutable,
movable и пр.), user-defined RTTI, таблица методов и пр.
- больше опций для scheduling-а тредов (типа disable preemption
тредов одной задачи, но возможность переключения между задачами),
нормальный набор классов для синхронизации (mutex, semaphore,
атомарные операции по записи данных и пр.)
- inner methods, включая анонимные inner методы (closures),
указатели на методы (в том числе как в функциональных
языках), и на код; указатели на фреймы методов
и возможность создавать фреймы в heap-е
- больше поддерживаемых методов вызова и диспатчинга методов -
tail recursion calls, multimethods и pattern-matched вызов
методов
- множественное наследование делегированием, через интерфейсы
(как в dylan), и как в С++
- security организована не через ACL (access control list),
а через возможность или невозможность получить доступ
к интерфейсу реализующему защищённую функциональность
ну, может что-то упустил

3. Язык программирования.
- код будет редактироваться и сохранятся в виде linked tree
базовых и определяемых программистом узлов
- синтаксис отстуствует как таковой, но для отображения
кода (то есть узлов дерева) и его редактирования можно
задавать свой синтаксис
- изменена система типов - тип, это просто набор constraints;
эти условия и ограничения могут использоваться для
верификации и оптимизации кода;
- в зависимости от "настроек" компиляции конкретного модуля
или метода, требуется более или менее жёсткое задание
constraints типов; например, в одном место NullPointerException
будет checked, а в другом нет - следовательно, в первом
месте надо будет задавать возможность указателя быть
или не быть null и делать проверки на null вручную,
а в другом месте можно это не указывать, и будут вставляться
проверки на null автоматически
- более тонкие настройки оптимизации, задание space/time оптимизации
для методов, более разнообразные call conventions;
- user-defined уровень доступа к полям и методам (а не фиксированный
набор - public/private/...); реализуется через view (аналог
SQL-ного view - у вас одна таблица, но можно создать много
виртуальных отображений этой таблицы) то есть множество
compile-time "интерфейсов" одного класса.
- встроенные узлы для trace/log/assert/throw позволяющие
автоматически генерировать (или не генерировать) трейс
или ассерты, выносить отладочные сообщения в debug
информацию (а не включать её в выполняемый код) и пр.
Вообще это будет не язык, а некая "заготовка". То есть
на его основе можно будет создавать "языки" от низкого
уровня (С/Pascal) до скриптов.
Поскольку синтаксис отсутствует, для редактирования необходим
будет специальный редактор (фактически IDE), и в этом
IDE можно будет редактировать и отлаживать весь код проекта
(хотя отдельные части кода и будут выглядеть "написанными"
на разных языках). Фактически этот IDE будет проводить
и аудит кода.

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

[Serguey Zefirov]

SZ>>>> Как ты сам понимаешь, если ты ее будешь делать на чем-то привычном, то
SZ>>>> как мы сможем проверить эту платформу? Если же ты будешь ее делать на
SZ>>>> ней же самой, то, получается, стоимость работы программиста для этой
SZ>>>> платформы превышает один миллион денег в год (несколько -- это
SZ>>>> обязательно больше двух).
MK>>> Hе, ну я же в смысле сметы, а не в смысле что сам накодирую :D
MK>>> Hу и "пара лет" - это в смысле демо-версии, на которой
MK>>> уже можно пускать бенчмарки, но не что-то реальное. А под
MK>>> бенчмарки и прочие крики о крутости - уже занимать у
MK>>> банков или на бирже реальные деньги, то есть десятки лимонов...
MK>>> Это же работа сравнимая с написанием c++/java/.net и пр. -
MK>>> за пару лет лаборатория может выдать на гора продукт,
MK>>> который уже раскручивается маркетологами долгие годы...
MK>>> [....] Когда технология
MK>>> уже будет более отработана (что лет пять, минимум) - тогда
MK>>> уже на персоналки и сервера можно.

SZ>> Что-то опять плохо выходит. ;)

SZ>> Что ты планируешь отрабатывать "лет пять" и чем это будет отличаться от
SZ>> современных технологий, которым тоже надо сравнимое время (.Net как раз
SZ>> и имеет возраст лет в пять)?
MK> Hу я тут писал кой-чего, это по отношению к Java.

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

Список я не стал критиковать, поскольку не знал, с чего начать. Все такое
вкусное! (C)

Тем не менее, за него отдельное спасибо. ;) Почерпнул кое-что полезное.

Yours truly, Serguey Zefirov (thesz AT mail DOT ru)

[Maxim Kizub]

Wed Jun 08 2005 13:22, Serguey Zefirov wrote to Maxim Kizub:

SZ>>>>> Как ты сам понимаешь, если ты ее будешь делать на чем-то привычном,
SZ>>>>> то как мы сможем проверить эту платформу? Если же ты будешь ее
SZ>>>>> делать на ней же самой, то, получается, стоимость работы
SZ>>>>> программиста для этой платформы превышает один миллион денег в год
SZ>>>>> (несколько -- это обязательно больше двух).
MK>>>> Hе, ну я же в смысле сметы, а не в смысле что сам накодирую :D
MK>>>> Hу и "пара лет" - это в смысле демо-версии, на которой
MK>>>> уже можно пускать бенчмарки, но не что-то реальное. А под
MK>>>> бенчмарки и прочие крики о крутости - уже занимать у
MK>>>> банков или на бирже реальные деньги, то есть десятки лимонов...
MK>>>> Это же работа сравнимая с написанием c++/java/.net и пр. -
MK>>>> за пару лет лаборатория может выдать на гора продукт,
MK>>>> который уже раскручивается маркетологами долгие годы...
MK>>>> [....] Когда технология
MK>>>> уже будет более отработана (что лет пять, минимум) - тогда
MK>>>> уже на персоналки и сервера можно.

SZ>>> Что-то опять плохо выходит. ;)

SZ>>> Что ты планируешь отрабатывать "лет пять" и чем это будет отличаться от
SZ>>> современных технологий, которым тоже надо сравнимое время (.Net как раз
SZ>>> и имеет возраст лет в пять)?
MK>> Hу я тут писал кой-чего, это по отношению к Java.

SZ> Я немного про другое писал -- если на доводку современной разработки до
SZ> уровня mainstream требуется пять лет, и твоей разработке тоже требуется
SZ> пять лет, то чем они отличаются для инвесторов? Я именно на это упирал.

Scalability. В платформах и времени.

Эту фиговину можно засунуть в телефон, и она будет как минимум
так-же защищена и удобна для разработки (кросс-девелопмент)
и сопровождения, как нынешний java/.net код, но работать будет
по производительности не хуже C, а флешки кушать в двое меньше.
Её можно засунуть в сервер, и оно будет работать лучше
нынешних решений. Java просто проигрывает по всем параметрам -
вообще по всем. .NEТ проиграет не так сильно по производительности
(хотя проиграет), но предлагаемая платформа на голову выше
в области "быстрой" и дешёвой разработки серверных приложений.

Во времени - это время жизни данной платформы - за счёт отказа
от фиксированных решений она имеет много больший потенциал
развития. Грубо говоря, Sun или MS вложили N-ое количество
бабок, и будут получать прибыль 10-15 лет. Здесь, при тех-же
вложенных деньгах, время активной жизни платформы будет
порядка 30 лет, соответственно процесс получения дивидендов
будет дольше, и общая сумма прибыли тоже.

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

В принципе, конечно, никто не даст полностью контролировать
данную платформу - либо её раздеребанят (как яву от Sun-а
сейчас IBM и Oracle отрывают), либо она не станет стандартом
(как .NET не станет, если MS не поделится контролем над ним).
Hо если хорошо поторговаться, то можно легко войти в Fortune 100,
стать на одном уровне с IBM, MS, Sun, HP, Nokia, etc.
И всего за какие-то несколько лимонов на разработку,
и потом несколько десятков лимонов на завоевание рынка.
Hорма прибыли - десятка на вложенный рупь.
Hу, риск тоже неслабый ;)

SZ> Список я не стал критиковать, поскольку не знал, с чего начать. Все такое
SZ> вкусное! (C)

SZ> Тем не менее, за него отдельное спасибо. ;) Почерпнул кое-что полезное.