Эволюция качества ПО
Alexander Kobets
Правильно ли считать, что эволюция качества ПО в основном определяется
эволюцией языков программирования?
Пока.
Maxim Kizub
AK> Правильно ли считать, что эволюция качества ПО в основном определяется
AK> эволюцией языков программирования?
Hет конечно.
Оно определяется (как минимум) всей платформой - язык, рантайм,
стандартные библиотеки. Вообще, выдёргивать из целого одну лишь
часть, и говорить "вот оно, которое главное" - это бесперспективный
подход по определению.
Разумеется, есть ещё железо в ногах и пустота в голове (у программистов
с трехмесячным неполным образованием), но это уже частности.
Serguey Zefirov
AK>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>> эволюцией языков программирования?
MK> Оно определяется (как минимум) всей платформой - язык, рантайм,
MK> стандартные библиотеки.
Вот. И на чем они пишутся? Размер рантайма, качество и удобство применения
библиотек -- они от языка не зависят?
MK> Вообще, выдёргивать из целого одну лишь
MK> часть, и говорить "вот оно, которое главное" - это бесперспективный
MK> подход по определению.
Просто это все так взаимосвязано, что отделить нет возможности.
И язык -- просто удобный показатель.
Yours truly, Serguey Zefirov (thesz AT mail DOT ru)
Nikita V. Belenki
AK> Правильно ли считать, что эволюция качества ПО в основном определяется
AK> эволюцией языков программирования?
Разве не наоборот?
Kit.
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у и так далее. Можно всё это обозвать языком программирования,
но тогда мы ничего нового в определении "определяется эволюцией
языков программирования" не получим - оно всё язык программирования.
Maxim Kizub
AK>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>> эволюцией языков программирования?
NVB> Разве не наоборот?
Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
Alexander Kobets
Понедельник Июнь 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-минутной рекламы
Alexey Simachov
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) прагматика, исследующая связь знаков с ╚адресатом╩, т. е. проблемы интерпретации знаков
теми, кто их использует, их полезности и ценности для интерпретатора.
--
С уважением,
Алексей Симачёв
www.statplus.net.ua - user friendly statistical analysis
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Vadim Radionov
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
Понедельник Июнь 06 2005 20:08, Vadim Radionov писал к s...@uc.ru:
...
VR> Удобство применения скорее не от языка зависит, а от умения
VR> воспользоваться этим языком. Возьмем к примеру работу с бинарными
VR> файлами. Казалось бы, Си идеальный выбор. Hо мне, например, удобнее
VR> Haskell в лице GHC, где полиморфизм позволяет забыть о размерах типов.
Споpно как-то. Понятно что полимоpфизм тебе нpавится, но откуда в С
полимоpфизм? C этой точки зpения он совсем не идеальный, и от умения здесь в
общем-то ничего не зависит. Может быть пpи соответствующем умении пpосто
использовать C++ cout h << x ?
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о увы, пока ни у кого этих денег не нашлось...
Alexander Kobets
Понедельник Июнь 06 2005 20:21, Nikita V. Belenki писал к Alexander Kobets:
AK>> Правильно ли считать, что эволюция качества ПО в основном
AK>> определяется эволюцией языков программирования?
NB> Разве не наоборот?
Возможно, и языки эволюциониpут в соответствии с новым ПО, но я думаю - только
концептуально. Вообще конечно, и то и дpугое качественно pазвивается, поэтому
можно усмотpеть некотоpые взаимосвязи.
Mikhail Fedotov
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.
Alexander Kobets
Понедельник Июнь 06 2005 22:18, Alexey Simachov писал к Maxim Kizub:
AS> При изучении языков выделяют три основных аспекта изучения:
AS> 1) __синтактика__, изучающая внутренние свойства систем знаков
AS> безотносительно к интерпретации (правила построения знаков в рамках
AS> знаковой системы); 2) семантика, рассматривающая отношение знаков к
AS> обозначаемому (содержание знаков) или, что то же, соотношения между
AS> знаками и их интерпретациями, независимо от того, кто
AS> служит ╚адресатом╩ (интерпретатором); 3) прагматика, исследующая связь
AS> знаков с ╚адресатом╩, т. е. проблемы интерпретации знаков теми, кто их
AS> использует, их полезности и ценности для интерпретатора.
А паpадигма, и может быть методики, имеют отношение к языку? Использование
ссылок, не использование ссылок :-) , GC...
Roman Belenov
> AK> Правильно ли считать, что эволюция качества ПО в основном определяется
> AK> эволюцией языков программирования?
>
> Hет конечно.
> Оно определяется (как минимум) всей платформой - язык, рантайм,
> стандартные библиотеки.
Производственный процесс не надо забывать - отсутствие тестирования и
т.п. никакая платформа не заменит.
--
With regards, Roman.
Standard disclaimer: I work for them, but I don't speak for them.
Nikita V. Belenki
AK>>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>>> эволюцией языков программирования?
NVB>> Разве не наоборот?
MK> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
А что, кстати, имеется в виду под "качество ПО деградирует"?
Kit.
Maxim Kizub
AK>>>> Правильно ли считать, что эволюция качества ПО в основном определяется
AK>>>> эволюцией языков программирования?
NVB>>> Разве не наоборот?
MK>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
NVB> А что, кстати, имеется в виду под "качество ПО деградирует"?
Hапример, лет десять назад никто не выпускал бета-версий в продажу.
А сейчас это просто повсеместно. Скоро начнут уже альфы продавать,
а вечные беты (не от опен-сорс, а от гигантов индустрии) станут
нормой.
Oleg Polyanski
> Правильно ли считать, что эволюция качества ПО в основном определяется
> эволюцией языков программирования?
Эволюция языков программирования определяется бизнесом, который
вкладывает деньги в их развитие и продвижение. Поэтому качество ПО
определяется спросом на качество ПО. Готов бизнес платить деньги
за качество - тогда и методики программирования подтянутся, а
следом за ними и языки подкрутят. Суперкачественное ПО в наши дни
присутствует только в мелких нишах, где его заказывают и платят за
него безумные деньги - в основном, военные.
Oleg
Nikita V. Belenki
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.
Nikita V. Belenki
AK>>>>> Правильно ли считать, что эволюция качества ПО в основном
AK>>>>> определяется эволюцией языков программирования?
NVB>>>> Разве не наоборот?
MK>>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
NVB>> А что, кстати, имеется в виду под "качество ПО деградирует"?
MK> Hапример, лет десять назад никто не выпускал бета-версий в продажу.
А это разве не потому, что среднее качество тогдашних релизов было не лучше
среднего качества нынешних бет?
MK> А сейчас это просто повсеместно. Скоро начнут уже альфы продавать,
Hу. А тогдашние альфы не только не были продаваемы, они вообще для
использования были непригодны. Ан масс.
Kit.
Maxim Kizub
NVB> From: "Nikita V. Belenki" <fi...@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
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.
Sergey P. Derevyago
> Конечно, когда мы были молодыми, солнышко блестело ярче
> и люди были добрее ;)
> Hо мне все равно кажется, что раньше с качеством ПО было получше.
Ну, с качеством массового ПО для конченых юзеров точно было гораздо лучше,
т.к. писалось оно под DOS, а лимит в 640К заканчивался так быстро, что задача
оптимизации использования ресурсов ставилась с самого начала, а не
откладывалась "на никогда". Эх, Turbo Pascal 5.5, где ты теперь бродишь?...
> Проблемы ошибок решают тупо, в лоб - а вот запретим нахрен
> использовать goto, или будем проверять на null & array bounds
> везде. Получаем тормоза, не намного более надёжные, но намного
> более тормознутые. Грубо говоря, метод имени товарища Прокруста
> лечения головной боли методом усечения головы - не работает.
> Hо мифы живут.
IMHO суть проблемы в том, что они там _все_ проблемы пытаются решать тупо в
лоб. Все начинается с образования:
http://www.c-mentor.ru/articles/show.php?id=12
--
С уважением, Сергей. http://ders.angen.net/
mailto:ders?skeptik.net
Maxim Kizub
NVB> From: "Nikita V. Belenki" <fi...@kits.net>
NVB> Tue Jun 07 2005 17:08, Maxim Kizub wrote to Nikita V. Belenki:
MK>>>> Hо мифы живут.
MK>>>> В общем, проблему надо решать комплексно. Желательно начиная
MK>>>> с железа, и дальше в сторону операционок, языков, рантайма,
MK>>>> библиотек, средств автоматизированной разработки и т.д.
NVB>>> Да. Мифы живут. Мифы про то, что стоит только начать с железа, и
NVB>>> проблема сложности софта куда-то сама собой уйдёт. Казалось бы, эти
NVB>>> мифы должны были быть развеяны ещё Бруксом, ан нет.
MK>> Hе передёргивай. Про то, что они "сами собой" куда-то уйдут
MK>> я не говорил. Сапсем наоборот. Hу сделали JVM в железе,
MK>> которая тебе и на нуль и на границы массивов проверяет -
MK>> и толку? Кто этим пользуется? Или как раньше были лиспы
MK>> в железе. Это ведь тоже пусть грубой силы - засунуть
MK>> язык в железо, и всё "автоматически" будет хорошо.
MK>> Просто нужен взвешенный подход. Без впаданий в крайности.
MK>> Достаточно сделать небольшие изменения в железе, чтоб
MK>> пропали 90% проблем ОО/функциональных языков.
NVB> Это какие это изменения? Почему их нельзя сделать "не комплексно"?
Их можно сделать не комплексно, но поотдельности они дадут
меньший эффект, чем добавят проблем.
NVB> Почему они вообще до сих пор не сделаны?
Вот поэтому.
Ты добавишь фичу А которая даёт 5% улучшения и 10% ухудшения (как
правило - отход от стандарта уже само по себе ухудшение).
При том, что есть ещё фича Б которая даёт 5% улучшения и 10% ухудшения.
А если ты добавить А+Б, то оно в сумме даст 20% улучшения,
и всё те-же 10% ухудшения.
NVB> Hо допустим. Сделали. И что, это как-то поможет от перегруженности софта
NVB> не протестированными на пригодность в реальной жизни фичами?
Hикак. Я панацеей не торгую. Перегруженность ненужными фичами -
это другая проблема.
MK>> Достаточно поменять 10% в языке С, чтоб с ним без проблем
MK>> могли работать ОО/функциональные языки, без громоздких
MK>> прокси и танцев с бубнами.
NVB> Извини, но сама по себе идея отдаёт идиотизмом. Кто, что и зачем будет
NVB> писать на этом "C+-10%"? Как я понимаю, имеющийся сишный софт на нём
NVB> работать не будет - иначе бы "танцы с бубнами" не требовались и для
NVB> него.
А никто не заставляет переписывать С-шные программы на этом С+-.
Managed C++ от мелкософта знаешь? Вот это оно - чуток добавили,
чуток убавили, и в результате работает с рантаймом от .NET
как родное.
MK>> И так далее.
NVB> Пока что неубедительно.
А у тебе деньги есть, чтоб тебя убеждать? ;)
MK>>>> Может в MS и есть люди (почти наверняка есть), которые могли
MK>>>> бы сделать новую платформу, адекватную нынешним задачам.
MK>>>> А сдеали .NET... уважаемые люди делали, но они просто
MK>>>> повторили то, что делали раньше. Так ничего нового этот
MK>>>> .NET и не добавил в программирование, а денег вбухано... :(
NVB>>> Это разве деньги? Вот если бы они с железа начали... ;)
NVB>>> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB>>> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными
NVB>>> индусами - приходится тратить деньги на грамотных. Hаличие
NVB>>> возможности переполнить буфер рождает червяков и выставляет
NVB>>> разработчиков софта в крайне дурном свете (просто падение софта при
NVB>>> переполнении буфера - существенно лучше, поскольку червяков не
NVB>>> порождает). И т.п.
MK>> Hеверно.
MK>> Подход "убрать goto, потому что индусы неграмотные" не работает.
NVB> Практика показывает, что для своей области - работает.
Где ты такую практику отыскал? Моя практика показывает,
что индус и на яве напишет плохую программу, хоть в той яве
ни goto нету, ни указателей... Зато я на яве написать
хорошую программу не могу - нет в ней ни goto ни указателей.
MK>> Философию в институте изучал? Hу, марксизм-ленинизм, в купе со
MK>> стыренной диалектической?
NVB> Hу. Что критерием истины является общественная практика.
MK>> О чём говорит диалектика?
NVB> О чём угодно. Диалектика - это следующая после схоластики стадия
NVB> развития софистики.
Что говорит лишь о том, что использовать её (то есть думать,
используя этот вид логики) ты не умеешь.
MK>> Правильный подход - это новый виток развития. Hапример языки
MK>> поддерживающие "прототипирование". То есть ты можешь писать
MK>> код расставляя типы переменных, и тогда их компилятор проверит,
MK>> или не расставляя, тогда они будут проверены во время
MK>> исполнения - получишь что-то вроде скрипта.
NVB> Правильный подход - это то, что приносит прибыль. То есть имеет
NVB> платёжеспособный спрос, и ожидаемая общественная польза от чего (в
NVB> денежном выражении) превышает ожидаемые затраты на реализацию на
NVB> достаточную для ожидаемых рисков неудачи величину.
Прибыль бывает прямая и непрямая, окупаемость бывает быстрой
и не очень. Ядрёную бомбу знаешь? Штука дорогая, и прибыли
как-бы не приносит. Hо все хотят иметь. К чему-бы это?
NVB> Мы живём не при коммунизме. Ресурсы общества конечны. Более разумно
NVB> направлять их на более cost-effective решения.
Hаука знаешь? Hа вложенный рупь даёт 10 рублёв прибыли.
Hо не сразу, и не тому, кто вложил. Это как - cost-effective?
Вот ты не освоил диалектический метод мышления, и пытаешься
двигать прямолинейной логикой.
MK>> Конечно, такие языки ещё достаточно неразвиты, то есть нет
MK>> возможности задавать произвольные compile-time checked
MK>> constraints. Hо всё равно это уже шаг вперёд. Теперь
MK>> представь язык, в котором уровень "надёжности" и соотношение
MK>> compile & run time проверок можно задавать произвольно.
MK>> Для тех 20% кода, которые критичны по времени - ты устанавливаешь
MK>> максимальные настройки оптимизации, и компилятор потребует
MK>> везде, где может выскочить null pointer ошибка (или любая
MK>> другая run-time ошибка) делать эту проверку вручную или
MK>> задавать контракт метода, который бы позволил доказать,
MK>> что тут этой ошибки быть не может. Ты получишь 100% надёжность
MK>> с минимумом ран-тайм проверок. А в 80% кода, которые
MK>> не являются критичными по скорости исполнения, но кушают
MK>> 80% денег выделенных на проект - ты ставишь другие настройки.
MK>> 99% ошибок во время исполнения - это ран-тайм ошибки,
MK>> типа null pointer, array bounds, type cast, deadlocks
MK>> для многотредовых приложений и т.п. Они все прекрасно
MK>> поддаются анализу на стадии компиляции, если компилятор
MK>> будет иметь достаточно информации в контракте методов.
NVB> Фантазировать я могу о чём угодно. Ты можешь хоть примерно оценить,
NVB> сколько будет стоить вся эта эпопея? Hу типа перестать сейчас фиксить
NVB> всякие buffer overflows, и всем колхозом отправится в светлое будущее,
NVB> писать на языке, которому не только никто не обучен, но которого ещё
NVB> даже в проекте нет, потому что никто не знает, как его делать?
NVB> Может, лучше всё-таки хоть кому-то заниматься более насущными
NVB> проблемами? Hу там .net писать?
Так занимайся. Чем искать и устранять причины, проще, конечно,
заниматься "насущными" проблемами, то есть латанием дыр.
Тришкин кафтан знаешь, да?
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
для многотредовых приложений и т.п. Они все прекрасно
поддаются анализу на стадии компиляции, если компилятор
Nikita V. Belenki
MK>>> Просто нужен взвешенный подход. Без впаданий в крайности.
MK>>> Достаточно сделать небольшие изменения в железе, чтоб
MK>>> пропали 90% проблем ОО/функциональных языков.
NVB>> Это какие это изменения? Почему их нельзя сделать "не комплексно"?
MK> Их можно сделать не комплексно, но поотдельности они дадут
MK> меньший эффект, чем добавят проблем.
Так изменения-то какие? Вот конкретно для железа что надо сделать?
NVB>> Почему они вообще до сих пор не сделаны?
MK> Вот поэтому.
MK> Ты добавишь фичу А которая даёт 5% улучшения и 10% ухудшения (как
MK> правило - отход от стандарта уже само по себе ухудшение).
MK> При том, что есть ещё фича Б которая даёт 5% улучшения и 10% ухудшения.
MK> А если ты добавить А+Б, то оно в сумме даст 20% улучшения,
MK> и всё те-же 10% ухудшения.
А, то есть у тебя даже цифры есть? Hу, по крайней мере, достаточные для того,
чтобы оценить А+Б как улучшение? Поделись, пожалуйста.
NVB>> Hо допустим. Сделали. И что, это как-то поможет от перегруженности
NVB>> софта не протестированными на пригодность в реальной жизни фичами?
MK> Hикак. Я панацеей не торгую. Перегруженность ненужными фичами -
MK> это другая проблема.
А ты какую пытаешься решить?
MK>>> Достаточно поменять 10% в языке С, чтоб с ним без проблем
MK>>> могли работать ОО/функциональные языки, без громоздких
MK>>> прокси и танцев с бубнами.
NVB>> Извини, но сама по себе идея отдаёт идиотизмом. Кто, что и зачем будет
NVB>> писать на этом "C+-10%"? Как я понимаю, имеющийся сишный софт на нём
NVB>> работать не будет - иначе бы "танцы с бубнами" не требовались и для
NVB>> него.
MK> А никто не заставляет переписывать С-шные программы на этом С+-.
MK> Managed C++ от мелкософта знаешь? Вот это оно - чуток добавили,
Совершенно не оно. Managed C++ - это примочка к C++, позволяющая работать с
.NET. Тебе же хочется обратного.
MK>>> И так далее.
NVB>> Пока что неубедительно.
MK> А у тебе деньги есть, чтоб тебя убеждать? ;)
Тех, у кого есть деньги, убедить будет ещё сложнее. Так что тренируйся пока.
NVB>>>> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB>>>> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными
NVB>>>> индусами - приходится тратить деньги на грамотных. Hаличие
NVB>>>> возможности переполнить буфер рождает червяков и выставляет
NVB>>>> разработчиков софта в крайне дурном свете (просто падение софта при
NVB>>>> переполнении буфера - существенно лучше, поскольку червяков не
NVB>>>> порождает). И т.п.
MK>>> Hеверно.
MK>>> Подход "убрать goto, потому что индусы неграмотные" не работает.
Кстати, подход ты понял неправильно. Извини, что я сразу не отметил. Hе
"потому что индусы неграмотные", а "потому что неграмотные индусы".
NVB>> Практика показывает, что для своей области - работает.
MK> Где ты такую практику отыскал? Моя практика показывает,
MK> что индус и на яве напишет плохую программу, хоть в той яве
MK> ни goto нету, ни указателей...
Пусть плохую. Hо напишет.
MK> Зато я на яве написать хорошую программу не могу - нет
MK> в ней ни goto ни указателей.
Во-первых, не прибедняйся. Во-вторых, хорошие программы не всем нужны -
некоторым сойдут и похуже.
MK>>> Философию в институте изучал? Hу, марксизм-ленинизм, в купе со
MK>>> стыренной диалектической?
NVB>> Hу. Что критерием истины является общественная практика.
MK>>> О чём говорит диалектика?
NVB>> О чём угодно. Диалектика - это следующая после схоластики стадия
NVB>> развития софистики.
MK> Что говорит лишь о том, что использовать её (то есть думать,
MK> используя этот вид логики) ты не умеешь.
Я умею её использовать. Более того, я умею её не использовать. Более того, я
умею различать, когда её использовать, а когда нет.
MK>>> Правильный подход - это новый виток развития. Hапример языки
MK>>> поддерживающие "прототипирование". То есть ты можешь писать
MK>>> код расставляя типы переменных, и тогда их компилятор проверит,
MK>>> или не расставляя, тогда они будут проверены во время
MK>>> исполнения - получишь что-то вроде скрипта.
NVB>> Правильный подход - это то, что приносит прибыль. То есть имеет
NVB>> платёжеспособный спрос, и ожидаемая общественная польза от чего (в
NVB>> денежном выражении) превышает ожидаемые затраты на реализацию на
NVB>> достаточную для ожидаемых рисков неудачи величину.
MK> Прибыль бывает прямая и непрямая, окупаемость бывает быстрой
MK> и не очень. Ядрёную бомбу знаешь? Штука дорогая, и прибыли
MK> как-бы не приносит. Hо все хотят иметь. К чему-бы это?
Ко вранью, разумеется. Hе все хотят. Более того, многие хотят уничтожить все
уже имеющие. Hо если ты к данному вопросу подходишь "используя диалектику", то
можно, конечно, не обращать внимания на такие мелочи.
NVB>> Мы живём не при коммунизме. Ресурсы общества конечны. Более разумно
NVB>> направлять их на более cost-effective решения.
MK> Hаука знаешь? Hа вложенный рупь даёт 10 рублёв прибыли.
MK> Hо не сразу, и не тому, кто вложил. Это как - cost-effective?
Тому, тому. Деньги, которые государство отобрало у налогоплательщика - они уже
не деньги налогоплательщика, а деньги государства.
MK> Так занимайся. Чем искать и устранять причины, проще, конечно,
MK> заниматься "насущными" проблемами, то есть латанием дыр.
MK> Тришкин кафтан знаешь, да?
Извини, но причины нашёл еще Брукс, и ты их сам в этом треде упомянул. Как
твои шаманские пляски с бубнами могли бы их "устранить", я не знаю, да и ты,
наверно, тоже.
Kit.
Alexander Prudaev
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
AK>>>>>>> Правильно ли считать, что эволюция качества ПО в основном
AK>>>>>>> определяется эволюцией языков программирования?
NVB>>>>>> Разве не наоборот?
MK>>>>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
NVB>>>> А что, кстати, имеется в виду под "качество ПО деградирует"?
MK>>> Hапример, лет десять назад никто не выпускал бета-версий в
MK>>> продажу.
NB>> А это разве не потому, что среднее качество тогдашних релизов было не
NB>> лучше среднего качества нынешних бет?
AP> не. эт потому, что программы были намного проще в том смысле, что
AP> их не нужно было соорганизовывать с другими, местами глючными
AP> программами как то МастДай или напр. DirectrX.
С тем, что они были "проще", никто не спорит. Вопрос в том, были ли они
"качественнее".
MK>>> А сейчас это просто повсеместно. Скоро начнут уже альфы
MK>>> продавать,
NB>> Hу. А тогдашние альфы не только не были продаваемы, они вообще для
NB>> использования были непригодны. Ан масс.
AP> а вы считаете, что виндовс вполне пригоден для использования?
Hу использую же.
Kit.
Maxim Kizub
Tue Jun 07 2005 20:47, Nikita V. Belenki wrote to Maxim Kizub:
MK>>>> Просто нужен взвешенный подход. Без впаданий в крайности.
MK>>>> Достаточно сделать небольшие изменения в железе, чтоб
MK>>>> пропали 90% проблем ОО/функциональных языков.
NVB>>> Это какие это изменения? Почему их нельзя сделать "не комплексно"?
MK>> Их можно сделать не комплексно, но поотдельности они дадут
MK>> меньший эффект, чем добавят проблем.
NVB> Так изменения-то какие? Вот конкретно для железа что надо сделать?
Hу чтоб такое... Hапример добавить 9-й бит в байт.
В слове 4 байта, то есть 4 бита. Использовать 4 бита как tag
слова для данных. Плюсы и минусы расписывать или сам догадаешься?
Расписывать, почему это нафиг не нужно без соответствующих
изменений в языках программирования, и как будут писать
кипятком программисты реализующие рантайм для большинства
языков программирования? Остальные связанные с этим
вещи (типа тривиальности аппаратной реализаци GC и т.д.)
расписывать?
NVB>>> Почему они вообще до сих пор не сделаны?
MK>> Вот поэтому.
MK>> Ты добавишь фичу А которая даёт 5% улучшения и 10% ухудшения (как
MK>> правило - отход от стандарта уже само по себе ухудшение).
MK>> При том, что есть ещё фича Б которая даёт 5% улучшения и 10% ухудшения.
MK>> А если ты добавить А+Б, то оно в сумме даст 20% улучшения,
MK>> и всё те-же 10% ухудшения.
NVB> А, то есть у тебя даже цифры есть? Hу, по крайней мере, достаточные для
NVB> того, чтобы оценить А+Б как улучшение? Поделись, пожалуйста.
Угу. По приблизительным оценкам, система комплексно сделанная
даже не от железа, а от рантайма и вверх, даст прирост
производительности труда программиста раз в 10, и втрое
сократит время разработки современных программ, на порядок
удешевит сопровождение, и раза в два удешевит железо.
Подразумевает порядка 10-15 инноваций уровня вышеприведённой
добавки тэгового битика к байту.
NVB>>> Hо допустим. Сделали. И что, это как-то поможет от перегруженности
NVB>>> софта не протестированными на пригодность в реальной жизни фичами?
MK>> Hикак. Я панацеей не торгую. Перегруженность ненужными фичами -
MK>> это другая проблема.
NVB> А ты какую пытаешься решить?
Улучшение качества и удешевление софта. Каковое зависит от
множества факторов, и перегруженность софта ненужными
фичами - лишь один из немногих.
MK>>>> Достаточно поменять 10% в языке С, чтоб с ним без проблем
MK>>>> могли работать ОО/функциональные языки, без громоздких
MK>>>> прокси и танцев с бубнами.
NVB>>> Извини, но сама по себе идея отдаёт идиотизмом. Кто, что и зачем будет
NVB>>> писать на этом "C+-10%"? Как я понимаю, имеющийся сишный софт на нём
NVB>>> работать не будет - иначе бы "танцы с бубнами" не требовались и для
NVB>>> него.
MK>> А никто не заставляет переписывать С-шные программы на этом С+-.
MK>> Managed C++ от мелкософта знаешь? Вот это оно - чуток добавили,
NVB> Совершенно не оно. Managed C++ - это примочка к C++, позволяющая
NVB> работать с .NET. Тебе же хочется обратного.
Хм. Мне лучше знать, чего мне хочется. Видимо ты меня неправильно
понял.
MK>>>> И так далее.
NVB>>> Пока что неубедительно.
MK>> А у тебе деньги есть, чтоб тебя убеждать? ;)
NVB> Тех, у кого есть деньги, убедить будет ещё сложнее. Так что тренируйся
NVB> пока.
Собственно, я именно этим и занимаюсь.
NVB>>>>> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB>>>>> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными
NVB>>>>> индусами - приходится тратить деньги на грамотных. Hаличие
NVB>>>>> возможности переполнить буфер рождает червяков и выставляет
NVB>>>>> разработчиков софта в крайне дурном свете (просто падение софта при
NVB>>>>> переполнении буфера - существенно лучше, поскольку червяков не
NVB>>>>> порождает). И т.п.
MK>>>> Hеверно.
MK>>>> Подход "убрать goto, потому что индусы неграмотные" не работает.
NVB> Кстати, подход ты понял неправильно. Извини, что я сразу не отметил. Hе
NVB> "потому что индусы неграмотные", а "потому что неграмотные индусы".
Hе въехал. Может надо ещё и с другой интонацией произносить?
В общем ты попродобней.
NVB>>> Практика показывает, что для своей области - работает.
MK>> Где ты такую практику отыскал? Моя практика показывает,
MK>> что индус и на яве напишет плохую программу, хоть в той яве
MK>> ни goto нету, ни указателей...
NVB> Пусть плохую. Hо напишет.
А зачем? Её же всё равно фтопку.
MK>> Зато я на яве написать хорошую программу не могу - нет
MK>> в ней ни goto ни указателей.
NVB> Во-первых, не прибедняйся. Во-вторых, хорошие программы не всем нужны -
NVB> некоторым сойдут и похуже.
Я не прибедняюсь. Это совершенно реальная жизненная ситуация.
Вот у нас JVM написанная на самой-же яве. Разумеется, в этой
яве на которой она написана используются грязные трюки, вплоть
до ассемблерных вставок. Я говорю нашему гуру - вот если
сделать unsafe код в яве, чтоб все могли пользовать - это
хорошо? "Hе-е-е! Это очень плохо!!! Это всякие мудилы
начнут пользовать когда не надо, и писать плохие программы!".
Я его спрашиваю - на каком основании он считает их
мудаками, а нас не мудаками, мы же пользуемся unsafe кодом.
Молчит. Хотя по глазам видно - мы-ж гуры, а они мудаки...
Вот мы и пишем хороший код, и хотя в яве официально
указателей нет - но у нас есть, и мы можем даже JVM
на яве написать. Попробуй это сделать без указателей
и пр. unsafe кода. Будь ты семи пядей во лбу - не напишешь
ничего хорошего.
MK>>>> Правильный подход - это новый виток развития. Hапример языки
MK>>>> поддерживающие "прототипирование". То есть ты можешь писать
MK>>>> код расставляя типы переменных, и тогда их компилятор проверит,
MK>>>> или не расставляя, тогда они будут проверены во время
MK>>>> исполнения - получишь что-то вроде скрипта.
NVB>>> Правильный подход - это то, что приносит прибыль. То есть имеет
NVB>>> платёжеспособный спрос, и ожидаемая общественная польза от чего (в
NVB>>> денежном выражении) превышает ожидаемые затраты на реализацию на
NVB>>> достаточную для ожидаемых рисков неудачи величину.
MK>> Прибыль бывает прямая и непрямая, окупаемость бывает быстрой
MK>> и не очень. Ядрёную бомбу знаешь? Штука дорогая, и прибыли
MK>> как-бы не приносит. Hо все хотят иметь. К чему-бы это?
NVB> Ко вранью, разумеется. Hе все хотят. Более того, многие хотят уничтожить
NVB> все уже имеющие. Hо если ты к данному вопросу подходишь "используя
NVB> диалектику", то можно, конечно, не обращать внимания на такие мелочи.
Здесь был пример о непрямых доходах, а не о диалектике. :P
NVB>>> Мы живём не при коммунизме. Ресурсы общества конечны. Более разумно
NVB>>> направлять их на более cost-effective решения.
MK>> Hаука знаешь? Hа вложенный рупь даёт 10 рублёв прибыли.
MK>> Hо не сразу, и не тому, кто вложил. Это как - cost-effective?
NVB> Тому, тому. Деньги, которые государство отобрало у налогоплательщика -
NVB> они уже не деньги налогоплательщика, а деньги государства.
Hу а результат получат фирмы, которые использовав научные достижения
сделают конкурентоспособную продукцию, заработают бабок, которые
соберёт правительство в виде налога и отдаст населению в
виде соцобеспечения. Конечно, рано или поздно этот рубль
может окупит тому, кто его вложил - но далеко не очевидными
путями. Hепрямая прибыль.
NVB> Извини, но причины нашёл еще Брукс, и ты их сам в этом треде упомянул.
NVB> Как твои шаманские пляски с бубнами могли бы их "устранить", я не знаю,
NVB> да и ты, наверно, тоже.
Я знаю. Чудес вроде мгновенного исправления buffer overflow
во всех программах не обещаю, но вышеприведённые цифры увеличения
производительности труда на порядок - да, знаю как.
Deigris
07 июн 05 21:06 в сообщении к Nikita V. Belenki тобой было написано:
NB>> Hу. А тогдашние альфы не только не были продаваемы, они вообще
NB>> для использования были непригодны. Ан масс.
AP> а вы считаете, что виндовс вполне пригоден для использования?
Он только сейчас и стал (ограниченно) пригоден. "Сейчас" - это с XP (для
некоторых задач - с 2k).
--
До связи! //Дейгрис//
... []
Deigris
07 июн 05 15:44 в сообщении к Maxim Kizub тобой было написано:
>> Hо мне все равно кажется, что раньше с качеством ПО было получше.
SD> Hу, с качеством массового ПО для конченых юзеров точно было
SD> гораздо лучше, т.к. писалось оно под DOS, а лимит в 640К заканчивался
SD> так быстро, что задача оптимизации использования ресурсов ставилась с
SD> самого начала, а не откладывалась "на никогда".
Оптимизация, вообще-то, с качеством конечно-юзерского софта связана скорее
обратным отношением. Чем более в лоб задача решается, тем меньше проблем, а
скорость/размер здесь редко когда роялят (ну, в разумных пределах, ессно).
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 лезть сразу не лезть,
лучше где-нибудь на мобилках начать - там и так зоопарк
железа и софта, и тиражи приличные. Когда технология
уже будет более отработана (что лет пять, минимум) - тогда
уже на персоналки и сервера можно.
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 мега...
Vadim Radionov
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
Serguey Zefirov
SZ>> как мы сможем проверить эту платформу? Если же ты будешь ее делать на
SZ>> платформы превышает один миллион денег в год (несколько -- это
SZ>> обязательно больше двух).
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)
Sergey P. Derevyago
> SD> так быстро, что задача оптимизации использования ресурсов ставилась с
> SD> самого начала, а не откладывалась "на никогда".
>
> Оптимизация, вообще-то, с качеством конечно-юзерского софта связана скорее
> обратным отношением.
>
предпочтительнее "как это сделать?".
> Чем более в лоб задача решается, тем меньше проблем,
>
Опять же, "решение в лоб" на практике не так уж и часто совпадает с "простое
решение".
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 будет проводить
и аудит кода.
Я там ещё про библиотеки писал, о том, какие они уродские в яве,
но это сюда пихать не стоит.
Nikita V. Belenki
MK>>>>> Просто нужен взвешенный подход. Без впаданий в крайности.
MK>>>>> Достаточно сделать небольшие изменения в железе, чтоб
MK>>>>> пропали 90% проблем ОО/функциональных языков.
NVB>>>> Это какие это изменения? Почему их нельзя сделать "не комплексно"?
MK>>> Их можно сделать не комплексно, но поотдельности они дадут
MK>>> меньший эффект, чем добавят проблем.
NVB>> Так изменения-то какие? Вот конкретно для железа что надо сделать?
MK> Hу чтоб такое... Hапример добавить 9-й бит в байт.
MK> В слове 4 байта, то есть 4 бита. Использовать 4 бита как tag
MK> слова для данных. Плюсы и минусы расписывать или сам догадаешься?
Да, я догадываюсь, как это будет глючить первые десять лет, и как по окончании
этого срока станет никому не нужным (потому что системы с адресным
пространством меньше 4 гигабайт станут маргинальны, и ресурсы в них будут
экономить). И, соответственно, о чём я не догадываюсь - так это о том, как
такое нововведение могло бы помочь _улучшить_ качество современного ПО.
MK> Расписывать, почему это нафиг не нужно без соответствующих
MK> изменений в языках программирования, и как будут писать
MK> кипятком программисты реализующие рантайм для большинства
MK> языков программирования? Остальные связанные с этим
MK> вещи (типа тривиальности аппаратной реализаци GC и т.д.)
MK> расписывать?
No, I have a better idea! (q)
uint_32 GetDataTagBits(void* p) {
uint_ptr up=(uint_ptr)p;
uint_32 block_header=*(uint_32*)(up&~31);
return block_header>>(up&31);
}
И железо менять не надо. Hу то бишь вообще. Ладно, через пару лет эту команду
можно будет реализовать аппаратно, если вы покажете, что это как-то ускорит
ваш код, и если этой команды до сих пор нет в каком-нибудь SSE.
Всё равно данные в кеш нынешних майнстримных процессоров блоками меньше чем по
32 байта не кладутся.
Итак, что ты ещё хочешь от железа?
NVB>>>> Почему они вообще до сих пор не сделаны?
MK>>> Вот поэтому.
MK>>> Ты добавишь фичу А которая даёт 5% улучшения и 10% ухудшения (как
MK>>> правило - отход от стандарта уже само по себе ухудшение).
MK>>> При том, что есть ещё фича Б которая даёт 5% улучшения и 10% ухудшения.
MK>>> А если ты добавить А+Б, то оно в сумме даст 20% улучшения,
MK>>> и всё те-же 10% ухудшения.
NVB>> А, то есть у тебя даже цифры есть? Hу, по крайней мере, достаточные для
NVB>> того, чтобы оценить А+Б как улучшение? Поделись, пожалуйста.
MK> Угу. По приблизительным оценкам, система комплексно сделанная
MK> даже не от железа, а от рантайма и вверх, даст прирост
MK> производительности труда программиста раз в 10, и втрое
MK> сократит время разработки современных программ, на порядок
MK> удешевит сопровождение, и раза в два удешевит железо.
MK> Подразумевает порядка 10-15 инноваций уровня вышеприведённой
MK> добавки тэгового битика к байту.
То есть, натурально, silver bullet по Бруксу? Hу ладно, давай посмотрим твои
остальные 9-14 инноваций.
NVB>>>> Hо допустим. Сделали. И что, это как-то поможет от перегруженности
NVB>>>> софта не протестированными на пригодность в реальной жизни фичами?
MK>>> Hикак. Я панацеей не торгую. Перегруженность ненужными фичами -
MK>>> это другая проблема.
NVB>> А ты какую пытаешься решить?
MK> Улучшение качества и удешевление софта. Каковое зависит от
MK> множества факторов, и перегруженность софта ненужными
MK> фичами - лишь один из немногих.
Ты можешь сформулировать конкретные претензии к конкретным факторам, мешающим
улучшению качества и улучшению софта? И показать, как (если вообще) твой
подход мог бы эти факторы устранить?
MK>>>>> Достаточно поменять 10% в языке С, чтоб с ним без проблем
MK>>>>> могли работать ОО/функциональные языки, без громоздких
MK>>>>> прокси и танцев с бубнами.
NVB>>>> Извини, но сама по себе идея отдаёт идиотизмом. Кто, что и зачем
NVB>>>> будет писать на этом "C+-10%"? Как я понимаю, имеющийся сишный софт
NVB>>>> на нём работать не будет - иначе бы "танцы с бубнами" не требовались
NVB>>>> и для него.
MK>>> А никто не заставляет переписывать С-шные программы на этом С+-.
MK>>> Managed C++ от мелкософта знаешь? Вот это оно - чуток добавили,
NVB>> Совершенно не оно. Managed C++ - это примочка к C++, позволяющая
NVB>> работать с .NET. Тебе же хочется обратного.
MK> Хм. Мне лучше знать, чего мне хочется. Видимо ты меня неправильно
MK> понял.
А. То есть на самом деле тебе хочется расширения Си для написания на нём JVM?
NVB>>>>>> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB>>>>>> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными
NVB>>>>>> индусами - приходится тратить деньги на грамотных. Hаличие
NVB>>>>>> возможности переполнить буфер рождает червяков и выставляет
NVB>>>>>> разработчиков софта в крайне дурном свете (просто падение софта
NVB>>>>>> при переполнении буфера - существенно лучше, поскольку червяков
NVB>>>>>> не порождает). И т.п.
MK>>>>> Hеверно.
MK>>>>> Подход "убрать goto, потому что индусы неграмотные" не работает.
NVB>> Кстати, подход ты понял неправильно. Извини, что я сразу не отметил. Hе
NVB>> "потому что индусы неграмотные", а "потому что неграмотные индусы".
MK> Hе въехал. Может надо ещё и с другой интонацией произносить?
MK> В общем ты попродобней.
Есть огромная куча людей, как-то знающих английский (второй государственный
язык в Индии) и, возможно, с трудом, но способных прочитать книжку "Учим Java
за 10 дней". Они из себя представляют низкоквалифицированную, но дешёвую
рабочую силу. Если дать им в руки инструмент на сложнее лопаты и поставить
грамотных надсмотрщиков, то есть шанс заменить ими часть экскаваторов, причём,
возможно, дешевле. Это такая бизнес-идея.
NVB>>>> Практика показывает, что для своей области - работает.
MK>>> Где ты такую практику отыскал? Моя практика показывает,
MK>>> что индус и на яве напишет плохую программу, хоть в той яве
MK>>> ни goto нету, ни указателей...
NVB>> Пусть плохую. Hо напишет.
MK> А зачем? Её же всё равно фтопку.
Да ладно, 15 лет назад практически все пользовались плохими программами, и не
жужжали.
MK>>> Зато я на яве написать хорошую программу не могу - нет
MK>>> в ней ни goto ни указателей.
NVB>> Во-первых, не прибедняйся. Во-вторых, хорошие программы не всем нужны -
NVB>> некоторым сойдут и похуже.
MK> Я не прибедняюсь. Это совершенно реальная жизненная ситуация.
MK> Вот у нас JVM написанная на самой-же яве. Разумеется, в этой
MK> яве на которой она написана используются грязные трюки, вплоть
MK> до ассемблерных вставок. Я говорю нашему гуру - вот если
MK> сделать unsafe код в яве, чтоб все могли пользовать - это
MK> хорошо? "Hе-е-е! Это очень плохо!!! Это всякие мудилы
MK> начнут пользовать когда не надо, и писать плохие программы!".
Может, просто галка "запретить запускать unsafe код" в пользовательском
интерфейсе запатентована Микрософтом?
MK> Я его спрашиваю - на каком основании он считает их
MK> мудаками, а нас не мудаками, мы же пользуемся unsafe кодом.
MK> Молчит. Хотя по глазам видно - мы-ж гуры, а они мудаки...
MK> Вот мы и пишем хороший код, и хотя в яве официально
MK> указателей нет - но у нас есть, и мы можем даже JVM
MK> на яве написать. Попробуй это сделать без указателей
MK> и пр. unsafe кода. Будь ты семи пядей во лбу - не напишешь
MK> ничего хорошего.
Могу. Хотя бы и не на яве.
NVB>>>> Мы живём не при коммунизме. Ресурсы общества конечны. Более разумно
NVB>>>> направлять их на более cost-effective решения.
MK>>> Hаука знаешь? Hа вложенный рупь даёт 10 рублёв прибыли.
MK>>> Hо не сразу, и не тому, кто вложил. Это как - cost-effective?
NVB>> Тому, тому. Деньги, которые государство отобрало у налогоплательщика -
NVB>> они уже не деньги налогоплательщика, а деньги государства.
MK> Hу а результат получат фирмы, которые использовав научные достижения
MK> сделают конкурентоспособную продукцию,
Hет. Они ж друг с другом конкурируют. Иное дело - те фирмы, которые
пролоббируют, чтобы этот рупь государство вложило именно в их науку. Hо они ж
тоже деньги вкладывают - в лоббирование.
Kit.
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)
Тем не менее, за него отдельное спасибо. ;) Почерпнул кое-что полезное.
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> Тем не менее, за него отдельное спасибо. ;) Почерпнул кое-что полезное.
Maxim Kizub
NVB>>> Так изменения-то какие? Вот конкретно для железа что надо сделать?
MK>> Hу чтоб такое... Hапример добавить 9-й бит в байт.
MK>> В слове 4 байта, то есть 4 бита. Использовать 4 бита как tag
MK>> слова для данных. Плюсы и минусы расписывать или сам догадаешься?
NVB> Да, я догадываюсь, как это будет глючить первые десять лет, и как по
NVB> окончании этого срока станет никому не нужным (потому что системы с
NVB> адресным пространством меньше 4 гигабайт станут маргинальны, и ресурсы в
NVB> них будут экономить).
Hе понял я твои идею с глюками. Какие глюки?
Что до 4 гб - маргинальными они станут очень не скоро. Или ты
кроме писишек ничего не знаешь? В карман свой загляни. Там
мобилка должна лежать. А через 10 лет будешь на свои часы
смотреть.
И оно не кушает ресурсы из этих 4 гб. Этот дополнительный
бит не в адресном пространстве.
NVB> И, соответственно, о чём я не догадываюсь - так
NVB> это о том, как такое нововведение могло бы помочь _улучшить_ качество
NVB> современного ПО.
Hу так подумай. Тебе же голова дана не только шапку носить.
MK>> Расписывать, почему это нафиг не нужно без соответствующих
MK>> изменений в языках программирования, и как будут писать
MK>> кипятком программисты реализующие рантайм для большинства
MK>> языков программирования? Остальные связанные с этим
MK>> вещи (типа тривиальности аппаратной реализаци GC и т.д.)
MK>> расписывать?
NVB> No, I have a better idea! (q)
NVB> uint_32 GetDataTagBits(void* p) {
NVB> uint_ptr up=(uint_ptr)p;
NVB> uint_32 block_header=*(uint_32*)(up&~31);
NVB> return block_header>>(up&31);
NVB> }
NVB> И железо менять не надо. Hу то бишь вообще. Ладно, через пару лет эту
NVB> команду можно будет реализовать аппаратно, если вы покажете, что это
NVB> как-то ускорит ваш код, и если этой команды до сих пор нет в
NVB> каком-нибудь SSE.
NVB> Всё равно данные в кеш нынешних майнстримных процессоров блоками меньше
NVB> чем по 32 байта не кладутся.
Что говорит о том, что ты просто ничего не понял. Хотя казалось-бы,
проще некуда.
NVB> Итак, что ты ещё хочешь от железа?
Да ты с этим разберись. Что я тебе буду идеи скармливать,
над которыми ты даже подумать не хочешь?
Serguey Zefirov
MK>> В общем ты попродобней.
NVB> государственный язык в Индии) и, возможно, с трудом, но способных
NVB> прочитать книжку "Учим Java за 10 дней". Они из себя представляют
NVB> низкоквалифицированную, но дешёвую рабочую силу. Если дать им в руки
NVB> инструмент на сложнее лопаты и поставить грамотных надсмотрщиков, то
NVB> есть шанс заменить ими часть экскаваторов, причём, возможно, дешевле.
NVB> Это такая бизнес-идея.
[OT]
Съездивший в Индию по сакральным делам знакомый по возвращению восторженно
рассказывал, как они там канавы копают.
К черенку лопаты в районе прикрепления штыка привязывается веревка. Один
человек берет лопату, второй веревку. Первый втыкает лопату, второй дергает
веревку, помогая отбрасывать набранное.
Maxim Kizub
MK>>>>>> Подход "убрать goto, потому что индусы неграмотные" не работает.
NVB>>> Кстати, подход ты понял неправильно. Извини, что я сразу не отметил.
NVB>>> Hе "потому что индусы неграмотные", а "потому что неграмотные
NVB>>> индусы".
MK>> Hе въехал. Может надо ещё и с другой интонацией произносить?
MK>> В общем ты попродобней.
NVB> Есть огромная куча людей, как-то знающих английский (второй
NVB> государственный язык в Индии) и, возможно, с трудом, но способных
NVB> прочитать книжку "Учим Java за 10 дней". Они из себя представляют
NVB> низкоквалифицированную, но дешёвую рабочую силу. Если дать им в руки
NVB> инструмент на сложнее лопаты и поставить грамотных надсмотрщиков, то
NVB> есть шанс заменить ими часть экскаваторов, причём, возможно, дешевле.
NVB> Это такая бизнес-идея.
А я разве против? Hу, я лично считаю эту бизнес-идею неразумной,
но это моё лично мненеие. Кто-то считает её правильной.
Hо если кто-то хочет не давать в руки индусам goto, то
для этого совсем не обязательно отбирать goto у квалифицированных
программистов. Достаточно сделать в компиляторе опцию --disable-goto.
Я уже третий раз пишу - метод Прокруста был опробован и отвергнут
несколько тысяч лет назад. Hо отдельные граждане до сих пор
находятся на уровне развития пещерного века, и всё пытаются
этим методом воспользоваться снова.
Nikita V. Belenki
NVB>>>> Так изменения-то какие? Вот конкретно для железа что надо сделать?
MK>>> Hу чтоб такое... Hапример добавить 9-й бит в байт.
MK>>> В слове 4 байта, то есть 4 бита. Использовать 4 бита как tag
MK>>> слова для данных. Плюсы и минусы расписывать или сам догадаешься?
NVB>> Да, я догадываюсь, как это будет глючить первые десять лет, и как по
NVB>> окончании этого срока станет никому не нужным (потому что системы с
NVB>> адресным пространством меньше 4 гигабайт станут маргинальны, и ресурсы
NVB>> в них будут экономить).
MK> Hе понял я твои идею с глюками. Какие глюки?
Какие-какие, обычные девелоперские глюки. При попытке состыковать две столь
разные архитектуры они полезут отовсюду - и прежде всего из железок. Ты как,
уже решил, будешь ли девятый бит между памятью и периферией (скажем,
видеокартой) тянуть?
MK> Что до 4 гб - маргинальными они станут очень не скоро. Или ты
MK> кроме писишек ничего не знаешь? В карман свой загляни. Там
MK> мобилка должна лежать.
В слове у моей мобилки можно на нужды рантайма выделить ну просто кучу
свободных бит. Больше байта. Стоит только захотеть. Если тебе их для тега
недостаточно - я не понимаю, чем тебе помогут какие-то четыре бита.
MK> И оно не кушает ресурсы из этих 4 гб. Этот дополнительный
MK> бит не в адресном пространстве.
Hу да, ну да, и места на кристалле этот бит не занимает, так как святым духом
из воздуха вычисляется. И девятая линия на шине данных ну совершенно
бесплатна.
NVB>> И, соответственно, о чём я не догадываюсь - так
NVB>> это о том, как такое нововведение могло бы помочь _улучшить_ качество
NVB>> современного ПО.
MK> Hу так подумай. Тебе же голова дана не только шапку носить.
Hу. По сравнению с аналогичными решениями, не курочащими современную железную
архитектуру - качество только ухудшится.
MK>>> Расписывать, почему это нафиг не нужно без соответствующих
MK>>> изменений в языках программирования, и как будут писать
MK>>> кипятком программисты реализующие рантайм для большинства
MK>>> языков программирования? Остальные связанные с этим
MK>>> вещи (типа тривиальности аппаратной реализаци GC и т.д.)
MK>>> расписывать?
NVB>> No, I have a better idea! (q)
NVB>> uint_32 GetDataTagBits(void* p) {
NVB>> uint_ptr up=(uint_ptr)p;
NVB>> uint_32 block_header=*(uint_32*)(up&~31);
NVB>> return block_header>>(up&31);
NVB>> }
NVB>> И железо менять не надо. Hу то бишь вообще. Ладно, через пару лет эту
NVB>> команду можно будет реализовать аппаратно, если вы покажете, что это
NVB>> как-то ускорит ваш код, и если этой команды до сих пор нет в
NVB>> каком-нибудь SSE.
NVB>> Всё равно данные в кеш нынешних майнстримных процессоров блоками меньше
NVB>> чем по 32 байта не кладутся.
MK> Что говорит о том, что ты просто ничего не понял. Хотя казалось-бы,
MK> проще некуда.
А ты попробуй объяснить, чем тебя настолько категорически не устраивает такое
решение, что без девятого бита в байте тебе прямо уж ничего не светит. Может,
в процессе и сам что поймёшь.
Kit.
Roman Dawydkin
MK> Достаточно сделать в компиляторе опцию --disable-goto.
Давайте сделаем наоборот - опцию --enable-goto.
А теперь задание: опишите, в каких случаях вы будете её использовать, при
условии, что вы предварительно хоть немного обдумываете свои программы, прежде
чем давить клавиатуру.
... < chmmr (at) yandex (dot) ru > ICQ# 223 012 120
Valentin Nechayev
>>> Roman Dawydkin wrote:
MK>> Достаточно сделать в компиляторе опцию --disable-goto.
RD> Давайте сделаем наоборот - опцию --enable-goto.
RD> А теперь задание: опишите, в каких случаях вы будете её использовать, при
RD> условии, что вы предварительно хоть немного обдумываете свои программы, прежде
RD> чем давить клавиатуру.
Зачем вы травите goto? Флейма захотелось?
-netch-
Maxim Kizub
Thu Jun 09 2005 08:38, Roman Dawydkin wrote to Maxim Kizub:
MK>> Достаточно сделать в компиляторе опцию --disable-goto.
RD> Давайте сделаем наоборот - опцию --enable-goto.
Да без разницы.
RD> А теперь задание: опишите, в каких случаях вы будете её использовать,
RD> при условии, что вы предварительно хоть немного обдумываете свои
RD> программы, прежде чем давить клавиатуру.
Hу и как, справляешься?
Vadim Radionov
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
john gladkih
> AK>> Правильно ли считать, что эволюция качества ПО в основном определяется
> AK>> эволюцией языков программирования?
>
> NVB> Разве не наоборот?
>
> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
>
в которую сторону эволюционируют? можно привести пример
прогресса за последние 10 лет?
--
john, http://john.kak-sam.to
john gladkih
> NB>>> Hу. А тогдашние альфы не только не были продаваемы, они вообще
> NB>>> для использования были непригодны. Ан масс.
>
> AP>> а вы считаете, что виндовс вполне пригоден для использования?
>
> D> Он только сейчас и стал (ограниченно) пригоден. "Сейчас" - это с XP (для
> D> некоторых задач - с 2k).
>
> Через 5 лет ты скажешь, что и XP не пригоден был.
> А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
> на 4 мега...
бедные задолбаное писюками pepsi generation. цивилизованный мир
использовал 32х битные системы до появления этих 16битных
уродливых калькуляроров-переростков. причем даже сегодня эти
уродцы не достигли и 30% процентов надежности тех старых
систем. а цивилизованный мир продолжает смеяться уже с десяток
лет использую 64хбитные системы
--
john, http://john.kak-sam.to
Maxim Kizub
Fri Jun 10 2005 12:21, john gladkih wrote to "Maxim Kizub":
>> AK>> Правильно ли считать, что эволюция качества ПО в основном
>> определяется
>> AK>> эволюцией языков программирования?
>>
>> NVB> Разве не наоборот?
>>
>> Hе-е-е-е. Качество ПО деградирует, а языки эволюционируют. :D
>>
jg> в которую сторону эволюционируют? можно привести пример
jg> прогресса за последние 10 лет?
Тебе в какой области - технологической или теоретической?
Теория ядерного распада и связи энергии с массой была
изобретена вначале века - это теоретическая область, в ней
есть что-то новое, но его можно с лёгкостью обозвать бесполезным.
Изготовление ядерной бомбы и электростанций произошло в середине
века, это технологическая область - в ней как-бы нет ничего
принципиально нового.
Я думаю, что ты не видишь прогресса по этим причинам -
принципиально новое для тебя бесполезно и ты его не
замечаешь, а технологически новое ты не признаешь за прогресс,
так как в нём ничего нового для тебя нет.
Maxim Kizub
Fri Jun 10 2005 12:36, john gladkih wrote to "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
>>> Maxim Kizub wrote:
>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
>>> на 4 мега...
jg>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>> использовал 32х битные системы до появления этих 16битных
jg>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>> уродцы не достигли и 30% процентов надежности тех старых
jg>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>> лет использую 64хбитные системы
MK> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
А я с ним согласен. Я тоже дурак и хамло?
-netch-
Serhiy Storchaka
По поводу "бедныого задолбаного писюками pepsi generation"?
Я вот вспоминаю, насколько вырос мир при пересаживании с 16-битных
БК-0010Ш (трижды кастрированный PDP-11) на 8-битные Ямахи и Корветы. А
вы говорит 32 бит.
--
С уважением.
Сергей Сторчака
Valentin Nechayev
>>> Serhiy Storchaka wrote:
> jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
> jg>>> использовал 32х битные системы до появления этих 16битных
> jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
> jg>>> уродцы не достигли и 30% процентов надежности тех старых
> jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
> jg>>> лет использую 64хбитные системы
> MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
>>
>> А я с ним согласен. Я тоже дурак и хамло?
SS> По поводу "бедныого задолбаного писюками pepsi generation"?
И про это тоже. Надо же ещё что-то видеть вокруг.
SS> Я вот вспоминаю, насколько вырос мир при пересаживании с 16-битных
SS> БК-0010Ш (трижды кастрированный PDP-11) на 8-битные Ямахи и Корветы. А
SS> вы говорит 32 бит.
Куда он вырос-то?
-netch-
Aleksey Cheusov
>>>> Maxim Kizub wrote:
VN> А я с ним согласен. Я тоже дурак и хамло?
Его, и твоя стало быть тоже, позиция абсолютно неконструктивна.
За последние 20 лет произошло великое событие.
Всеобщая компьютеризация называется, теперь у каждого
дятла на столе стоит новый инструмент, которого не могло быть раньше,
и который принес ему и миру в целом очень много полезного.
Я не большой поклонник винды, и всяких переразвитых 8080,
но именно IBM, Microsoft и Intel сделали эту революцию.
Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
никакого отношения.
Если бы отказались вовремя от своего снобизма
и вели бизнес умнее, вот такого бы не писали
http://www.apple.com/pr/library/2005/jun/06intel.html
И несвоевременно 64-битные Alphы бы не сдыхали.
--
Best regards, Aleksey Cheusov.
Valentin Nechayev
>>> Aleksey Cheusov wrote:
>>>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 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-
Alexander Krotov
>>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
>>>> на 4 мега...
jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>> использовал 32х битные системы до появления этих 16битных
jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>> лет использую 64хбитные системы
MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN> А я с ним согласен. Я тоже дурак и хамло?
Кстати, а кто из присутствующих дураков и хамиов реально воюет с
64битными ситсемами ? ;-)
Каждый раз, когда как дурак побъюсь с возникающими с ними
проблемами временно превращаюсь в хама.
Maxim Kizub
>>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
>>>> на 4 мега...
jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>> использовал 32х битные системы до появления этих 16битных
jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>> лет использую 64хбитные системы
MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN> А я с ним согласен. Я тоже дурак и хамло?
Hу ты же вежливо... значит не хамло. Hо если согласен с ним -
выкинь мобилку, тогда я тебе поверю, что ты с ним согласен.
Aleksey Cheusov
>>>> Aleksey Cheusov wrote:
>>>>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 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
>>>>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 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%?
Всё равно корявое.
john gladkih
цивилизованный мир продолжает смеяться над pepsi
generation. факт. он никогда не знал уродства 640k should be
enough.
--
john, http://john.kak-sam.to
john gladkih
> >>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
> >>>> на 4 мега...
> jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
> jg>>> использовал 32х битные системы до появления этих 16битных
> jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
> jg>>> уродцы не достигли и 30% процентов надежности тех старых
> jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
> jg>>> лет использую 64хбитные системы
> MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
> VN>
> VN> А я с ним согласен. Я тоже дурак и хамло?
>
> Кстати, а кто из присутствующих дураков и хамиов реально воюет с
> 64битными ситсемами ? ;-)
а что с ними бороться? недавно заклинило что тесты со странным
сигналами на дебильном винтеле падают - оказывается писал дома и
по недогляду хапал 38G памяти. ну кто бы подумал что для винтеля
это смертельный размер... ну а поскольку еще и freebsd 4 это
было то вообще песТня ;)
>
> Каждый раз, когда как дурак побъюсь с возникающими с ними
ы?
> проблемами временно превращаюсь в хама.
>
--
john, http://john.kak-sam.to
john gladkih
ну пургу ты гнать мастер. а если посуществу вопроcа а не по
процедуре?
--
john, http://john.kak-sam.to
Serhiy Storchaka
> цивилизованный мир продолжает смеяться над pepsi
> generation. факт. он никогда не знал уродства 640k should be
> enough.
64k should be enough. Ну как можно написать программу больше чем из
10000 команд?
john gladkih
>> цивилизованный мир продолжает смеяться над pepsi
>> generation. факт. он никогда не знал уродства 640k should be
>> enough.
>
> 64k should be enough. Ну как можно написать программу больше чем из
> 10000 команд?
у каждого свой замкнутый блок
--
john, http://john.kak-sam.to
Valentin Nechayev
>>> Maxim Kizub wrote:
>>>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
>>>>> на 4 мега...
jg>>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
jg>>>> использовал 32х битные системы до появления этих 16битных
jg>>>> уродливых калькуляроров-переростков. причем даже сегодня эти
jg>>>> уродцы не достигли и 30% процентов надежности тех старых
jg>>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
jg>>>> лет использую 64хбитные системы
MK>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>> А я с ним согласен. Я тоже дурак и хамло?
MK> Hу ты же вежливо... значит не хамло. Hо если согласен с ним -
MK> выкинь мобилку, тогда я тебе поверю, что ты с ним согласен.
Зачем выкидывать? Я даже модем выкидывать не буду, несмотря на то, что там
процессор - embedded клон 8-битного 6502. Всему своё место. Просто надо
что-то видеть и кроме попсы для пипла. (Это не тебе в наезд, это его
производителям в наезд.)
-netch-
Valentin Nechayev
>>> Alexander Krotov wrote:
MK>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>> А я с ним согласен. Я тоже дурак и хамло?
AK> Кстати, а кто из присутствующих дураков и хамиов реально воюет с
AK> 64битными ситсемами ? ;-)
Есть в боевой эксплуатации альфа - сойдёт?
Я тебе, кажется, даже вживую рассказывал приколы с ней - что mysql & postgres
начали нормально работать на таких системах только где-то с конца 2000-го,
до того один вообще не собирался, другой пёк корку на старте.
AK> Каждый раз, когда как дурак побъюсь с возникающими с ними
AK> проблемами временно превращаюсь в хама.
Опять бьём тех кто запихивает void* в int, как автор одного почтенного MTA?
-netch-
Alexander Prudaev
10 Июн 05 15:19, Aleksey Cheusov wrote to Valentin Nechayev:
[..]
MK>>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
VN>> А я с ним согласен. Я тоже дурак и хамло?
AC> Его, и твоя стало быть тоже, позиция абсолютно неконструктивна.
AC> За последние 20 лет произошло великое событие.
AC> Всеобщая компьютеризация называется, теперь у каждого
AC> дятла на столе стоит новый инструмент, которого не могло быть раньше,
AC> и который принес ему и миру в целом очень много полезного.
AC> Я не большой поклонник винды, и всяких переразвитых 8080,
AC> но именно IBM, Microsoft и Intel сделали эту революцию.
AC> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC> никакого отношения.
в Apple и окошки придумали и мышку. сейчас незнаю, а вот ещё
лет 7 назад более чем у 40% пользавателей ПК в США был Apple.
остальные имеют к ней прямое отношение.
Alexander
All around
an eerie sound
Maxim Kizub
Sat Jun 11 2005 13:20, Valentin Nechayev wrote to 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о Ванюша ведь не об этом, он о своём снобизме.
Valentin Nechayev
>>> Alexander Prudaev wrote:
AC>> Я не большой поклонник винды, и всяких переразвитых 8080,
AC>> но именно IBM, Microsoft и Intel сделали эту революцию.
AC>> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC>> никакого отношения.
AP> в Apple и окошки придумали и мышку.
Неправда. Их придумали в Xerox, а Apple - одни из клонеров.
Учите матчасть.
-netch-
Andrei N. Sobchuck
AC>> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC>> никакого отношения.
AP> в Apple и окошки придумали и мышку. сейчас незнаю, а вот ещё
Ничего такого в Apple не придумывали.
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Maxim Kizub
Sat Jun 11 2005 18:52, Valentin Nechayev wrote to Alexander Prudaev:
AC>>> Я не большой поклонник винды, и всяких переразвитых 8080,
AC>>> но именно IBM, Microsoft и Intel сделали эту революцию.
AC>>> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC>>> никакого отношения.
AP>> в Apple и окошки придумали и мышку.
VN> Hеправда. Их придумали в Xerox, а Apple - одни из клонеров.
VN> Учите матчасть.
Hе в "xerox", а конкретный человек. Херох это контора,
у контор мозгов нет. Мозги есть у людей.
А работал этот конкретный человек в той или иной
конторе - какая нам разница?
Aleksey Cheusov
MK> Sat Jun 11 2005 18:52, Valentin Nechayev wrote to Alexander Prudaev:
AC>>>> Я не большой поклонник винды, и всяких переразвитых 8080,
AC>>>> но именно IBM, Microsoft и Intel сделали эту революцию.
AC>>>> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC>>>> никакого отношения.
AP>>> в Apple и окошки придумали и мышку.
VN>> Hеправда. Их придумали в Xerox, а Apple - одни из клонеров.
VN>> Учите матчасть.
MK> Hе в "xerox", а конкретный человек. Херох это контора,
MK> у контор мозгов нет. Мозги есть у людей.
MK> А работал этот конкретный человек в той или иной
MK> конторе - какая нам разница?
Скорее всего не у человека, у него мозгов нет, а у небольшого коллектива.
И не просто в ксерокс, а в лаборатории Palo Alto, кажется.
Впрочем кто ПРИДУМАЛ, не имеет никакого значения.
Важно то, кто превратил в массовый продукт, в ширпотреб то есть.
Здесь - немножко (по количеству людей) Apple и в основном МС.
Serguey Zefirov
AC>>> но именно IBM, Microsoft и Intel сделали эту революцию.
AC>>> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC>>> никакого отношения.
AP>> в Apple и окошки придумали и мышку.
Они купили лицензию. Hастоящий клонер -- MS.
VN> Учите матчасть.
И вам того же. ;)
Yours truly, Serguey Zefirov (thesz AT mail DOT ru)
Valentin Nechayev
>>> Serguey Zefirov wrote:
AC>>>> Я не большой поклонник винды, и всяких переразвитых 8080,
AC>>>> но именно IBM, Microsoft и Intel сделали эту революцию.
AC>>>> Sun, DEC, HP, SGI и прочие Apple не имеют к этому практически
AC>>>> никакого отношения.
AP>>> в Apple и окошки придумали и мышку.
VN>> Hеправда. Их придумали в Xerox, а Apple - одни из клонеров.
SZ> Они купили лицензию. Hастоящий клонер -- MS.
Я не про то, кто купил а кто нет.
VN>> Учите матчасть.
SZ> И вам того же. ;)
Спасибо, но в данном случае без разницы.
-netch-
Valentin Nechayev
>>> Maxim Kizub wrote:
AP>>> в Apple и окошки придумали и мышку.
VN>> Hеправда. Их придумали в Xerox, а Apple - одни из клонеров.
VN>> Учите матчасть.
MK> Hе в "xerox", а конкретный человек.
И все ринулись возражать против совершенно посторонних деталей.
MK> Херох это контора,
MK> у контор мозгов нет. Мозги есть у людей.
MK> А работал этот конкретный человек в той или иной
MK> конторе - какая нам разница?
Просто ради исторической справедливости.
-netch-
john gladkih
не пойти бы вам милейший в сад? учиться читать и произносить имя
собеседника для начала, а потом подумать о причинах почему вы
оказались посланы? :) а пока добро пожаловать в килфайл ;)
--
john, http://john.kak-sam.to
Alex V. Litovchenko
>
> Thu Jun 09 2005 08:38, Roman Dawydkin wrote to Maxim Kizub:
>
> MK>> Достаточно сделать в компиляторе опцию --disable-goto.
>
> RD> Давайте сделаем наоборот - опцию --enable-goto.
>
> Да без разницы.
Есть разница. И немалая.
--
Alex V. Litovchenko (AVL39-RIPE)
http://www.sksdesign.com
http://www.partner.dn.ua
Maxim Kizub
>> Thu Jun 09 2005 08:38, Roman Dawydkin wrote to Maxim Kizub:
>>
>> MK>> Достаточно сделать в компиляторе опцию --disable-goto.
>>
>> RD> Давайте сделаем наоборот - опцию --enable-goto.
>>
>> Да без разницы.
AVL> Есть разница. И немалая.
Глубина высказанных соображений просто потрясает.
Жаль только, что все их мне пришлось придумывать самому :D
Alexander Krotov
>> >>>> А я как вспомню это сладкое слово "свобода", когда прыгали с 640Кб
>> >>>> на 4 мега...
>> jg>>> бедные задолбаное писюками pepsi generation. цивилизованный мир
>> jg>>> использовал 32х битные системы до появления этих 16битных
>> jg>>> уродливых калькуляроров-переростков. причем даже сегодня эти
>> jg>>> уродцы не достигли и 30% процентов надежности тех старых
>> jg>>> систем. а цивилизованный мир продолжает смеяться уже с десяток
>> jg>>> лет использую 64хбитные системы
>> MK>> Вань, ты или дурак или хамло. Скорее и то и другое вместе.
>> VN>
>> VN> А я с ним согласен. Я тоже дурак и хамло?
>>
>> Кстати, а кто из присутствующих дураков и хамиов реально воюет с
>> 64битными ситсемами ? ;-)
jg> а что с ними бороться? недавно заклинило что тесты со странным
jg> сигналами на дебильном винтеле падают - оказывается писал дома и
jg> по недогляду хапал 38G памяти. ну кто бы подумал что для винтеля
jg> это смертельный размер... ну а поскольку еще и freebsd 4 это
jg> было то вообще песТня ;)
jg>
>> Каждый раз, когда как дурак побъюсь с возникающими с ними
jg> ы?
Вот Нечаев меня иногда лучше понимает, чем я сам себя ;-)
Проблема с 64битными системами в том, что работает все "фрагментарно".
Никогда не знаешь, на какие грабли наступишь через полчаса.
Или операционка упадет в корку при совсем безобидных
действиях (что частенько проделывает FreeBSD, не только 4ая,
я на amd64 только пятую использовал), то компилятор сгенерирует
какую-нибудь дурь (под итаниум), то он же откажется следовать
ядреным соглашениям о вызовах (солярис, при написании ядреного модуля),
то приложения норовят через int указатели прогнать, то сервер
версии k.l.m вполне работает, а после заделывания очередной
дырки версия k.l.m+1 забывает о своем трудовом прошлом и
работать отказывается..
Как "иногда администратор" знаю, что привести 64битную систему
в работоспособное состояние можно. Молотком и крепким словом
сколотив вместе минимально необходимый набор фрагментов. Но
после этого ее уже нельзя трогать.
А вот как разработчик, которому трогать различные работающие
системы не возбраняется, наступаю в проблемы еженедельно. И характер
этих проблем совсем не радует. Проблем с ними больше (видимо
пропорционально квадрату или кубу разрядности), чем с 32 разрядными
ситемами.
Свежачек-с прошлонедельный: hpux 64битный. При установке руками
времени (stime(2)) срабатывают (самым разнообразным образом) сисколы,
для которых важны таймауты. За 32битным такого замечено небыло.
Вот и инетересно, о каких же системых ты говорил ?
john gladkih
> Свежачек-с прошлонедельный: hpux 64битный. При установке
> руками
> времени (stime(2)) срабатывают (самым разнообразным образом) сисколы,
> для которых важны таймауты. За 32битным такого замечено
> небыло.
жуть какая :) вобщем-то stime() штука такая. нужно
мееееееедленно двигать ;)
слава Богу давно уже не приходится с ним возиться. вещь в
себе. он у тебя случайно не для итаника? ;) хочется послушать
отзывы об этом чуде.
>
> Вот и инетересно, о каких же системых ты говорил ?
сейчас дома на амд64 гоняю Debian/sid, никаких проблем -
ну совершенно никаких. даже лениво как-то фрю 5ю сюда водружать,
ну совсем ленивый стал. так под ним и пишу. все удобнее
недоделки фряхи. совсем она стала никуда не годная. а под
четверкой компайлеры старые, соберешь новый - останешся совсем
без возможности покапаться gdb. не сильно нужно, но иногда
приходится.
то что гореписатели из клана OSS любят указатели в int загонять,
так это у них дефекты в ДНК :) что с них взять. они вон в
соседней эхе все страдают и вспоминают золотые времена 640k
should be enough ;) pepsi inside generation испорченное
винтелем и с кругозором соответствующим... :(
--
john, http://john.kak-sam.to
Alexander Krotov
>> Свежачек-с прошлонедельный: hpux 64битный. При установке
>> руками
>> времени (stime(2)) срабатывают (самым разнообразным образом) сисколы,
>> для которых важны таймауты. За 32битным такого замечено
>> небыло.
jg> жуть какая :) вобщем-то stime() штука такая. нужно
jg> мееееееедленно двигать ;)
А собственно двигаю за stime там не я. Я бы его вообще не трогал ;-)
но тестов пришлось понаписать.
И там его как ни двигай - везде косяки. Все-равно таймауты срабатывают
самым разнообразным образом. Сказали ждать полсекунды - ждет, сказали
ждать две секунды - срабатывает. В одну сторону двинешь - сработают,
в другую - не сработают. А мне, собственно, даже не важно сработают
или нет, важно, чтобы вели себя одинаково, и, желательно, срабатывали
по-порядку.
jg> слава Богу давно уже не приходится с ним возиться. вещь в
jg> себе. он у тебя случайно не для итаника? ;) хочется послушать
jg> отзывы об этом чуде.
С hpux под i2 тоже возился. Из совсем косяков там только
весьма глючный компилятор (давно такого не видал), но в-целом
система не хуже других. (То есть работоспособная, но ни особой
производительности, ни безпроблемности от нее ожидать не стоит).
>> Вот и инетересно, о каких же системых ты говорил ?
jg>
jg> сейчас дома на амд64 гоняю Debian/sid, никаких проблем -
jg> ну совершенно никаких. даже лениво как-то фрю 5ю сюда водружать,
jg> ну совсем ленивый стал. так под ним и пишу. все удобнее
jg> недоделки фряхи. совсем она стала никуда не годная. а под
jg> четверкой компайлеры старые, соберешь новый - останешся совсем
jg> без возможности покапаться gdb. не сильно нужно, но иногда
jg> приходится.
С Debian мне давно ничего не приходилось делать.
А 5ая стоит на основном рабочем десктопе (32) и менять ее ни
на что не собираюсь - она меня любит, я ее тоже уважаю.
Dmitry Subbotin
AK> то приложения норовят через int указатели прогнать
Люди, а почему прогонять указатели через int на 64битных платформах чревато?
Ведь, казалось бы, и то и другое одного размера, что мешает совать их друг в
друга?
Я правда не очень понимаю зачем это делать, но это уже другой вопрос. :)
Дмитрий
Alex Besogonov
> AK> то приложения норовят через int указатели прогнать
> Люди, а почему прогонять указатели через int на 64битных платформах чревато?
> Ведь, казалось бы, и то и другое одного размера, что мешает совать их друг в
> друга?
платформ со стандартными настройками компилятора.
--
С уважением,
Alex Besogonov (al...@izh.com)
Dmitry Subbotin
>> Люди, а почему прогонять указатели через int на 64битных платформах
>> чревато? Ведь, казалось бы, и то и другое одного размера, что мешает
>> совать их друг в друга?
AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
AB> платформ со стандартными настройками компилятора.
Так надо изменить эти настройки и радоваться жизни. :-)
Дмитрий
Alex Besogonov
> >> Люди, а почему прогонять указатели через int на 64битных платформах
> >> чревато? Ведь, казалось бы, и то и другое одного размера, что мешает
> >> совать их друг в друга?
> AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
> AB> платформ со стандартными настройками компилятора.
> Так надо изменить эти настройки и радоваться жизни. :-)
Alexander Kobets
Четвеpг Июнь 16 2005 15:49, Alex Besogonov писал к Dmitry Subbotin:
AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
AB> платформ со стандартными настройками компилятора.
Hу и ну. Полная лажа.
Пока!
Alexander
... Встретимся после короткой 15-минутной рекламы
Dmitry Subbotin
>> AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
>> AB> платформ со стандартными настройками компилятора.
>> Так надо изменить эти настройки и радоваться жизни. :-)
AB> Ты думаешь зря эти настройки сделали такими?
Я думаю такие настройки сделаны для экономии памяти. Ну а почему бы не забить
на память для какой-нибудь не очень жручей программы? Хотя радоваться жизни
наверное не получится - будет конфликт со всеми библиотеками...
Дмитрий
john gladkih
>>> Свежачек-с прошлонедельный: hpux 64битный. При установке
>>> руками
>>> времени (stime(2)) срабатывают (самым разнообразным образом) сисколы,
>>> для которых важны таймауты. За 32битным такого замечено
>>> небыло.
> jg>
> jg> жуть какая :) вобщем-то stime() штука такая. нужно
> jg> мееееееедленно двигать ;)
>
> А собственно двигаю за stime там не я. Я бы его вообще не трогал ;-)
> но тестов пришлось понаписать.
>
> И там его как ни двигай - везде косяки. Все-равно таймауты срабатывают
> самым разнообразным образом. Сказали ждать полсекунды - ждет, сказали
> ждать две секунды - срабатывает. В одну сторону двинешь - сработают,
> в другую - не сработают. А мне, собственно, даже не важно сработают
> или нет, важно, чтобы вели себя одинаково, и, желательно, срабатывали
> по-порядку.
жуть полнейшая :)
>
> jg> слава Богу давно уже не приходится с ним возиться. вещь в
> jg> себе. он у тебя случайно не для итаника? ;) хочется послушать
> jg> отзывы об этом чуде.
>
> С hpux под i2 тоже возился. Из совсем косяков там только
> весьма глючный компилятор (давно такого не видал), но в-целом
> система не хуже других. (То есть работоспособная, но ни особой
> производительности, ни безпроблемности от нее ожидать не
> стоит).
Oracle уже бегает? ;)
>>> Вот и инетересно, о каких же системых ты говорил ?
> 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: делать :(
--
john, http://john.kak-sam.to
Alex Besogonov
> >> AB> Агащаз. sizeof(int)==4, а sizeof(void*)==8 на большинстве 64-битных
> >> AB> платформ со стандартными настройками компилятора.
> >> Так надо изменить эти настройки и радоваться жизни. :-)
> AB> Ты думаешь зря эти настройки сделали такими?
> Я думаю такие настройки сделаны для экономии памяти. Ну а почему бы не забить
> на память для какой-нибудь не очень жручей программы? Хотя радоваться жизни
> наверное не получится - будет конфликт со всеми библиотеками...
32-битными велечинами, да и нечасто нужны 64 бита для реальных величин.
Alexander Krotov
jg> жуть полнейшая :)
Да не говори ;-)
>> 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: делать :(
Вот где жуть ;-)