COBOL v5 – A ‘Brave’ New World

[flip_flop]

Что понимается под "проектированию и использованию именно облаков "? если тех кто пишет хайпервайзеры или там EC2 c VPC то это не я, но знаком с работавшими в AWS. если внедрение облаков в жисть консервативной конторы - то

Расскажите про жисть. И про причины доминирования х86, не только по дешевизне, но и по другим факторам. Я вижу результат (рост прибыли для нашего железа (> 10%) максимален именно для облаков, даже превосходит HPC, не говоря об enterprise servers) но интересна механика этого процесса.

[mskmel]

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

Ето развитие технологии накопителей, в данном случаe backup типа...
К х86 железкам не имеет никакого отношения, по крайней мере удешевление етих самых накопителей и увеличение обьемов етих накопителей.
На безумно дорогих и старых технологиях накопутелей естественно было невозможно, но тогда ето было особо и не нужно, обьeмы данных было на много порядков ниже.

Для дедубликации таких объёмов надо очень большое количество памяти, а на МФ до сих пор единицами ГБ всё измеряется. Да и несчастной парой тыщ МИПСов 2ГБ\сек не пожмешь\дедублицируешь (это производительность на одну ноду HP 6500). Именно количественный рост ядер\гигагерц\гигабайт привёл к возможности качественного изменения целого пласта железок (ленты). С количественным ростом произошло смещение разумного баланса между задачами решаемыми софтом и железом.
Сейчас не пытаются реализовать в железе всё и вся как раньше, это сильно дороже и не так гибко, по сравнению c дешевыми процессорами\памятью и сверху прикрученным софтом.

[zVlad]

.....
Примите мои извинения за обиды, вольные и невольные.

Давайте ещё Вы скажете, что погорячились в цитате про "ничего нового в архитектуре Intel процессоров с 2000x годов" и наступит полная гармония. В свою очередь я делюсь своим искренним убеждением в том, что прогресс есть и в архитектуре процессоров для МФ и в архитектуре процессоров для OpenPower и в архитектуре многих других процессоров от IBM, один TrueNorth чего стоит. Убеждение основано на знаниях и не зависит от пыла дискуссий на форумах.

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

Вместо того чтобы согласиться что я погорячился сказав неприятные для Вас вещи про уважаемые Вами платформы я постораюсь Вас же убедить что это так, и постараюсь понять, надеюсь с Вашей же помощью, до какой степень это так. Пока я соглашусь с тем что что то в архитектуре Интел появлялось нового, собственно Вы уже назвали что и мне это нужно будет изучить и показать что на то что имелось в виду это не оказало влияние или согласиться что я был неправ на 100%.
А имелось в виду следущее. Вот мы имеем аппаратную платформу, грубо говоря компьютер, на ней стоит некая ОС и с этой ОС выполняются некие приложения. С изменение аппаратной платформы может а может и нет изменяться ОС, принципы ее работы, возможности, возможно архитектура самой ОС. И следовательно меняется стиль и возможности на прикладном уровне, программы пишутся иначе и результат оказывается другим.
Вот это я имел в виду, что, как мне кажется, с начала 2000-х (где то тогда появились 64 бит процессора и ОС безусловно отразила это в себе и приложения тоже, появилась виртуализация и Интел сделал некоторые движения чтобы она была полноценной) ничего такого, революционного в Интел и в ОС для Интел больше не произошло. То что появились много коровы и много сокетные сервера, а также мульттрединг, это всего лишь последствие достижения физического ограничения по тактовой частоте. Мультипроцессирование появилось раньше и в принципе это как бы уже состоялось, т.е. ничего нового, количественные изменения.
Появление облаков это тоже вынужденная мера. Стало накладно, тяжело и дорого надувать мыльный пузырь прайвет дата центров, где добрая половина оборудования элементарно простаивает. Перед этим кстати был период консолидации серверов, как мы помним, очень короткие и не очень внятный (ИБМ тогда тоже провел свою консолидацию серверов, на МФ, которая была весьма эффективной для ИБМ). Кстати до консолидации был движение SOA - сервис орентированная архитектура.

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

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


Вот примерно об этом я думал "горячась". И вопрос влияния на качество написания програм поднятый АРАРАТом тоже весьма интересен и ждет наших размышлений и обсуждений.

[zVlad]

..
.... а) Вы про JIT слышали?
(б) Гы. Смотрел я на дизассемблер выхода С++ компилятора. Не "ужас", а "ужас-ужас!!! "

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

Я имел в виду простой С.

[mskmel]

(а) Вы про JIT слышали?

JIT не даст разницу на два порядка, байткод не так плох. Тут именно умение эффективно реализовывать алгоритмы.

[zVlad]

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

Облако на западном побережье получается ждало что у вас случится DR и оставляло для этого некие ресурсы чтобы принять Вашу нагрузку? Наверное все таки облако то работало над другими нагрузками. Тогда откуда все таки могли появиться там ресурсы для Вас если Вы за них ничего не платили? Я вот этого не могу понять.

похоже придется начать издалека.. но побудьте со мной - оно того стоит.
zVlad, Вы отчасти правы, что под луной ничто не ново.. как Алан наш Тюринг завещал если язык Turing complete то на нем можно сделать все тоже что на другом Turing complete аминь. Вот только развивается не по циклу а спирали - количество в качество и на новый виток.
AWS это не просто гигантские площади заставленные супердешевыми x86 в дещевом месте около дешевого лепестиричества.... это 10+ регионов в каждом по несколько "авалабилити зон" каждая в свою очередь может быть не один датацентр. Т.е. частные облака по размеру тут рядом не стояли.. просто потому что.. ну это как лимонад который школьницы из лимонов добывали vs производства пепси с колой.

лет 10+ назад IBM пытался продать клиентам: "пока у Вас простаивает будет ранатся батч джоб, а как нагрузка пойдет так освободится для срочных задач. заплатите в 2 раза больше за лицензию.. зато на томже софто-харде сделаете в 2-4 раза больше" - это было лажей.. т.к. срочные задачи не плавно расползались по суткам а происходили одномоментно при закрытии дня, итд....
так вот, теперь этот подход таки оказался не лажей - компют стал настоящим комодитиз. сотни тысяч покупателей со всего шарика таки имеют сильно разные потребности - кому-то нужно именно в Орегоне, комуто совершенно пофиг где. кто-то предпочитает заплатить сразу за N лет вперед, кто-то согласен сделать ставку в .2 бакса за час сервера и не возражает если его сервер прибьют как только цена поднимется до .2001.
так что ресурсы не простаивали, просто за них платили дешевле или как раз попользовались и возвращали когда они мне понадобились.
допускаю, что если восточное побережё смоет, а др-нутся все планировали с востока именно на запад, причем конкретно в Орегон а не кали.. то там может оказаться напряг. пока такого не случалось.. впрочем катрин у амазона, вроде и не смыла ничего..
MS кстати AWS догоняет - говорят что у них аж 24 региона и все соединены темным файбером кроме китайского (там по закону темным нельзя) ... короче становится уму нерастяжимо КАКОЕ количество в качество переходит

Я внимательно прочитал все что Вы написали. И тоже прошу остаться со мной до конца того что я напишу сейчас. Но это не ответ на мой вопрос. И я думаю Вы и сами это понимаете.
Теперь подробнее. Начну с частностей. Про МФ Вы сказали. Идея которую Вы назвали лажей, хотя тут же и оговорились но как бы переключившись на другую платформу, совсем не лажа. Она, я имею в виду то что имеет в виду ИБМ - work load manager wLM, кстати не требует чтобы срочные работы выстраивались сами в очередь, это было бы действительно лажаей никому не нужной. Для упрощения понимания и сокращения количества букв приведу недавний пример из моей практики. К нам обратились с жалобой на долгое ожидание печати которая вызывалась из диалогового процесса и нужна была сразу. Это не отчеты были а маленькие печати типа накладных на ширинг-ресивинг, где ждать понятное дело некогда. Оказалось (мы это знали конечно) что печать выполнена была нашими программистами как батчджобс и естественно попадала в сервис клас (service class) для батчес, т.е. довольно низкий по значимости (importance) класс. И как раз у нас начались долгие периоды когда процессора на сто оказались загружеными и мы судорожно пытались понять почему (в итоге поняли и устранили это другая история). Что мы сделали доя печати? Выделили батчи печати в отдельный класс выполнения (execution class in JES - job entry system) и создали в WLM для этого класса выполнения правило связи (classification rule) его с сервис классом диалоговой работы. Эти батчи стали вылетать пулей и поскольку ресурсов доя их выполнения требовалось немного то и диалоги не пострадали. А прочие батчи остались на низком уровне, но на их время выполнения никто не жаловался, никто их не ждал. Потом причина загрузки на сто процессоров была найдена и устранена. Смысл в наших настройках печатных работ в принципе исчез, но мы оставили их поскольку если почему либо опять будет сто то никто уде жаловаться не будет.

Теперь вернемся к облакам и DR. Есть конечно такие бизнесы на восточном побережьи что если их смоет то никто уже не побежит на западное. Но есть и такие что если для них не окажется ресурсов в случае потери продакшн сайта то произойдет еще бОльший DR чем тот что смыл продакшн. Я имею тот бизнес для которого работаю - атомная энергетика, хотя есть и другии аналогичные бизнес. Вот для них та неопределенность на которую Вы получается полагаетесь в облаках совершенно не приемлема. Тем не менее я могу себе представить как эти требования могут быть удовлетворены облаками, но уже будут совсем другие деньги. И это будет выглядить примерно так. На западном побережье облако загружено на сто, восточное смыло и есть бизнесы с восточного которым гарантирован был ДР сайт (за деньги), из облака на западе выхеривается столько пользователей, которым ничего не гарантировалось, сколько нужно чтобы принять бизнесы с востока. Или если всем сервис гарантировался то тогда облако на западе должно будет иметь столько неиспользуемых ресурсов сколько нужно для ДР ситуации на востоке. Чудес не бывает.
Напомню, у нас два МФ оба загружены и один это одна десятая от другого и мы платим за ни в примерно такой же пропорции. В случае потери более мощного МФ менее мощный делается даже более мощным чем первый и все перемещается на него. За эту возможность мы тоже платим, но меньше чем если оба МФ были одинаковы всегда, гораздо меньше, на порядки.

[geek7]

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

Это не от спецов писавших на Коболе произошло, не важно как они писали. Это от того что Кобол компилятор выдает код исполняемый непосредственно на CPU компьютера, а Java компилятор выдает байткод интерпретируемый Java виртуальной машиной. Издержки на интерпретацию. А интерпретация это дань объектно-ориетируемости Java, где без преобразования типов не выполнить элементарного сложения. Это мы проходили еще в 90-е года на SmallTalk. Тоже получилось бы если бы писали на простом С.

Это как раз тот жемчуг.. просто россыпью. zVlad Вы думаете JIT так фатально уступает компилятору кобола и С что одна и та-же логика будет выполнятся "часы, по сравнению с неделями на предыдущих языках"?
ну допустим руки у писавших Джаву на МФ не просто кривые - загнуты не под углом, а завиты в узел и там разница не в %% а разы.. хотя мне это представить сложно. Все проблемы жавной производитльности которой слышал (не говоря уж сталкивался) были в обращении с памятью - генерировалось много объектов, а потом в не очень подходящий момент собирались.. т.е. получался временный затык. на выполнение длительного расчета это существенного влияния не окажет (да и коллекторы обзавелись новыми алгоритмами + Фреймворки обектоплодящие вымирают)
Чтобы разница была на порядки - это нужно фундаментально облажатся... например не запаралеллить то что составляет суть вычислений и таки параллелиться.
Справедливости ради надо сказать, что некоторые языки таки паралелят то, что программер залабал как одно последовательное вычисление например Скала (там это правда часть языка) ... в Джава нужно стрим использовать (т.е. хоть и не програмиш сам паралелизм таки напрямую разрешаешь)... но к Коболу это вроде не относится. во всяком случае в списке его нет:
https://en.wikipedia.org/wiki/Implicit_parallelism" onclick="window.open(this.href);return false;

ну и "интерпретация это дань объектно-ориетируемости Java" ставит под сомнение существование "С с крестами"

[geek7]

Что понимается под "проектированию и использованию именно облаков "? если тех кто пишет хайпервайзеры или там EC2 c VPC то это не я, но знаком с работавшими в AWS. если внедрение облаков в жисть консервативной конторы - то

Расскажите про жисть. И про причины доминирования х86, не только по дешевизне, но и по другим факторам. Я вижу результат (рост прибыли для нашего железа (> 10%) максимален именно для облаков, даже превосходит HPC, не говоря об enterprise servers) но интересна механика этого процесса.

про жисть? жисть хороша не уверен какие подробности Вас интересуют
причины доминирования х86, не только по дешевизне - ну какие еще могут быть причины? если задача решается методом А за 10$ а Б за 99$ то будут решать А. Я думаю всем совершенно пофиг что за неонка там внутрях и то, что тут называлось мэнфреймовым клаудом не получило широкого применения примерно по той причине по которой нютон не пошел, а ойфон побежал с писком. Цена и исторический момент позволяли его впихивать только богатеньким клиентам для узких целей и для тех большинство юзало более дешевые варианты.. а х86 оказалась более дешевым вариантом в нужный момент. Был бы АРМ - были бы облака сейчас на АРМ.. и запросто еще будет если производительность на ват будет так отличатся, что станет сильно выгодней х86.
А что у Вас за железо?

[Palych]

Или если всем сервис гарантировался то тогда облако на западе должно будет иметь столько неиспользуемых ресурсов сколько нужно для ДР ситуации на востоке. Чудес не бывает.

Чудо в том, что ресурсы в облаке дешевые.
Держать в 2-3 раза больше серверов чем нужно, загружать их на 10-25%. Если что-то вылетит - останется меньше доступных серверов, нагрузка на них будет скажем 30%.
Потому как благодаря унификации серверов нет необходимости держать ровно столько же серверов в альтернативном месте.

[zVlad]

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

да легко
viewtopic.php?f=46&t=200877&start=125#p6271189" onclick="window.open(this.href);return false;

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

Про Citrix. Citrix не уменьшает ни количества клиентов ни количества приложений. Citrix только создает видимость бОльшей изолированности информационных ресурсов от посягательств разного рода недобрых людей. Нам так объясняют: клиент не хочет чтобы (читай клиента убедили в том чтобы мы со своими сраными десктопами находились в его сети. Поэтому мы должны работать через Citrix сервер где каждому из нас к каждому нужному нам приложению будет запускаться клиент картинку с которого нам будут присылать на наш тонкий клиент. Было расследование попыток подобрать пароли к известным аккаунтам чтобы зайти на защищенные приложения на МФ. Быстро вычислили IP адрес, это оказался Citrix сервер и порт с которого делались потыки. Citrix персонал сказал у них нет информации чтобы протрассировать дальше до IP c которого делались эти попытки. Но мне этим не нравится идея, мне она не нравится тем что моя возможность работать с высоконадежным и производительным МФ ставится в зависимость от низконадежного и порой очень непроизводительного сервера Citrix.
Никаких принципиально новых возможносте с появлением дешевого харда вовсе не появилось. Наоборот по первости эти новые дешевые железки с их дешевый софтом показывали не более чем теже возможности но с гораздо меньшей надежностью. Оракл по началу был настоящим уродцем годным только для систем принятия решений (забыл абревиатуру) но что было то было всю экономию от покупли железа отдавали Лэри Элисону. Это не я придумал, это я прочитал у тех кто был там и тогда и даже с самим Лэри общались. В том и дело что цена условной единицы пользы ИТ ни при каких псевдореволюциях не менялась, а лишь перераспределялась иначе. И этот прием оказался весьма заразительным.

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

[geek7]

Я внимательно прочитал все что Вы написали. И тоже прошу остаться со мной до конца того что я напишу сейчас. Но это не ответ на мой вопрос. И я думаю Вы и сами это понимаете.
Теперь подробнее. Начну с частностей. Про МФ Вы сказали. Идея которую Вы назвали лажей, хотя тут же и оговорились но как бы переключившись на другую платформу, совсем не лажа. Она, я имею в виду то что имеет в виду ИБМ - work load manager wLM

лажа - имелось в виду с коммерческой т.з. для потенциальных клиентов. я с wLM столкнулся в следующей реинкарнации - надстройке над вебсферой. тут суть н в технологической тонкости\продвинутости а разные задачи одной компании vs задачи сотен тысяч компаний.

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

Я же сказал, что есть разные варианты с соответствующими ценами включая торги в реальном времени (когда устанавливается верхняя граница и срвер убивается когда рыночная цена ее пересекает) есть и гарантированный доступ на N месяцев\лет.
НО понятно что охватывают в первую очередь 90% типичных потом подбираются к остальным 10%.
например уже несколько лет есть специальный регион - "гавермент" для их регулейшенс.
кстати, думаю МФ если и пойдт в клауд, то последними.
Для большинства же риск, что под ДР не будет ресурсов вполне премлем... причем даже в Вашей конторе наверняка не все задачи в случае проблемы с ДР приводят к взрыву - есть всякие аудиты, архивы HR, CRM итд которые еще на SaaS не перевели

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

ну пусть другие ... но не настолько и совсем другие

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

Что крутится на 9\10 второго МФ?
В случае AWS это и вычисление рекламы которую Вам покажут при следующей покупке онлайн и стартап школьника Васи, который решил что у него гениальная идея по получению бабок на анализе форекса за последние N лет и еще 10000 разных стартапов и больших компаний

[geek7]

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

да легко
viewtopic.php?f=46&t=200877&start=125#p6271189" onclick="window.open(this.href);return false;

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

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

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

ну может другой продукт..

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

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

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

Вы экономию от масштабов не отрицаете часом?

[zVlad]

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

Ето развитие технологии накопителей, в данном случаe backup типа...
К х86 железкам не имеет никакого отношения, по крайней мере удешевление етих самых накопителей и увеличение обьемов етих накопителей.
На безумно дорогих и старых технологиях накопутелей естественно было невозможно, но тогда ето было особо и не нужно, обьeмы данных было на много порядков ниже.

Для дедубликации таких объёмов надо очень большое количество памяти, а на МФ до сих пор единицами ГБ всё измеряется. Да и несчастной парой тыщ МИПСов 2ГБ\сек не пожмешь\дедублицируешь (это производительность на одну ноду HP 6500). Именно количественный рост ядер\гигагерц\гигабайт привёл к возможности качественного изменения целого пласта железок (ленты). С количественным ростом произошло смещение разумного баланса между задачами решаемыми софтом и железом.
Сейчас не пытаются реализовать в железе всё и вся как раньше, это сильно дороже и не так гибко, по сравнению c дешевыми процессорами\памятью и сверху прикрученным софтом.

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

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

[zVlad]

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

Это не от спецов писавших на Коболе произошло, не важно как они писали. Это от того что Кобол компилятор выдает код исполняемый непосредственно на CPU компьютера, а Java компилятор выдает байткод интерпретируемый Java виртуальной машиной. Издержки на интерпретацию. А интерпретация это дань объектно-ориетируемости Java, где без преобразования типов не выполнить элементарного сложения. Это мы проходили еще в 90-е года на SmallTalk. Тоже получилось бы если бы писали на простом С.

Это как раз тот жемчуг.. просто россыпью. zVlad Вы думаете JIT так фатально уступает компилятору кобола и С что одна и та-же логика будет выполнятся "часы, по сравнению с неделями на предыдущих языках"?
ну допустим руки у писавших Джаву на МФ не просто кривые - загнуты не под углом, а завиты в узел и там разница не в %% а разы.. хотя мне это представить сложно. "

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

[Easbayguy]

Можно начать принимать ставки, через сколько дней Zvlad вернется!