Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 [12] 13 14 15   вперед  Ctrl
 Re: Yukon почти не виден  [new]
ЛП
Guest
ChA
ЛП
Было сказано, что это удобные фичи (т.е. с ними приятнее и быстрее).
Вся беда в том, что польза этих удобств совершенно неочевидна.

Это другой вопрос. Но и при ответе на этот вопрос количество инсталяций не является критерием ни "ненужности", ни "неудобности" фичей.
9 окт 05, 15:28    [1951962]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Yo!!

я где-то когда-то сказал неправду о mssql ?


ЛП

Был выложен список фичей Sybase ASA. Было сказано, что это не критичные фичи (т.е. без них жить можно). Было сказано, что это удобные фичи (т.е. с ними приятнее и быстрее). Было сказано, что несмотря на отсутствие удобных фичей - можно и на сиквеле проекты реализовывать, покряхтев, попердев, где-то руками, где-то ногами, где-то полураком через жопу, но можно. И в ответ фраза "Да разумеется можно, вы поглядите сколько инсталяций у сиквела!". Да сколько бы ни было инсталяций у сиквела - репликация не станет столь же удобной, как у Sybase'а, и обработки исключений в 2000-ом не появится.

А в моем-то ответе вам что не понравилось ? Я согласен с тем, что судить по одним лишь инсталляциям - не совсем объективно. Но тем не менее - это фактор, который нельзя совсем игнорировать. Я также сказал, что накрутив тонну-другую "удобных" фичей - вы тоже не гарантируете успех продукта, ибо большая масса их рискует оказаться невостребованной, а то, что окажется полезным - вполне реализуемо и без специальных фич, и вовсе необязательно через жопу.
9 окт 05, 15:34    [1951967]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ЛП
Guest
А в моем-то ответе вам что не понравилось ?

Да не, все нормально.
Я согласен с тем, что судить по одним лишь инсталляциям - не совсем объективно.

Иногда можно судить и по одним лишь инсталяциям. Смотря о чем судить собираемся.
Иногда можно судить и по одним лишь фичам. Опять таки смотря о чем судить собираемся.
Но нельзя с одного на другое перескакивать. Ибо сравнения СУБД по функциональным возможностям и по распространенности - это два разных сравнения, они ортогональны. Нельзя сравнивать теплое и мягкое.
9 окт 05, 15:41    [1951974]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ChA
Member

Откуда: Москва
Сообщений: 11377
ЛП
Это другой вопрос. Но и при ответе на этот вопрос количество инсталяций не является критерием ни "ненужности", ни "неудобности" фичей.
Ответ был на это
ASCRUS
А я и не спорю, что при желании, времени и силах на MSSQL можно сделать нормальный проект.
, а не список фич, как таковой. "Нормальность" проекта по Вашему тоже определяется этим списком ? Т.е., фичи есть, так и желания не надо, и времени, не то что сил. Все само делается, грузится и отправляется потребителю :) Именно поэтому и был помянут рынок, который проголосовал денежкой и количеством инсталяций как косвенное, но немаловажное,доказательство, что действительно, можно на MSSQL делать вполне успешные проекты, даже если какие-то фичи, которых как кроликов у конкурентов, отсутствуют. Не будем же мы всерьез считать, что только недоумки, которым некуда девать время(см. выше по списку) покупают MSSQL ради него самого по причине мазохизма ?
9 окт 05, 16:03    [1951992]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Как Yo не дает покоя DB Mirroring.
Будет он с выходом Юкона, будет.
Есть "но", в тестовом режиме, официально включат в первом СП. По крайней мере так говорил докладчик на TechNet. Да и выпустят Юкон по словам того же докладчика все-таки 7 ноября.
9 окт 05, 17:15    [1952033]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ChA
ЛП
Это другой вопрос. Но и при ответе на этот вопрос количество инсталяций не является критерием ни "ненужности", ни "неудобности" фичей.
Ответ был на это
ASCRUS
А я и не спорю, что при желании, времени и силах на MSSQL можно сделать нормальный проект.
, а не список фич, как таковой. "Нормальность" проекта по Вашему тоже определяется этим списком ? Т.е., фичи есть, так и желания не надо, и времени, не то что сил. Все само делается, грузится и отправляется потребителю :) Именно поэтому и был помянут рынок, который проголосовал денежкой и количеством инсталяций как косвенное, но немаловажное,доказательство, что действительно, можно на MSSQL делать вполне успешные проекты, даже если какие-то фичи, которых как кроликов у конкурентов, отсутствуют. Не будем же мы всерьез считать, что только недоумки, которым некуда девать время(см. выше по списку) покупают MSSQL ради него самого по причине мазохизма ?

Перечисленные и неперечисленные мною "фичи", как для архитектора проектов означают во первых облегчение кода бизнес-логики в БД, во вторых открывают более широкие возможности по реализации сложной бизнес-логики в БД. Что это дает:
1. Требуется написание меньшего по обьему кода, что приводит к меньшему кол-ву ошибок, более легкому проектированию и сопровождению проекта.
2. Приводит к меньшему кол-ву ньюансов, что снижает требования к специалистам с большим опытом работы с данной СУБД, фактически с FB, MSSQL, Oracle специалист достаточно легко обучается и начинает нормально работать с ASA, без последствий наткнуться на ошибки проектирования из за того, что не были учтены какие то ньюансы в силу малого опыта работы.
3. Расширенная функциональность позволяет организовывать собственные мощные и конкуретноспособные проекты, обладающие рядом уникальных характеристик. Ко всему прочему большая область применения РСУБД позволяет не задумываясь реализовывать кроссплатформенные решения, решения для мобильных технологий, для удаленного доступа по слабым каналам или без каналов связи, для интеграции с другими крупными системами на крупных коммерческих РСУБД (вплоть до репликации), для создания автономных самоадминистрирующихся одно и многопользовательских систем с встроенным РСУБД для сбора и анализа информации, написание тиражируемых продуктов и прочее.

Что все это дает ? Все эти 3 пункта дают меньшие риски при написании проектов, меньшую стоимость самих проектов по сравнению с использованием других коммерческих РСУБД из за более дешевых лицензий, более легкое и дешевое обучение и стоимость специалистов, более легкое сопровождение проектов. Сложно наверное себе представить консолидированный MSSQL с 10 000 удаленных узлов по репликации без какого либо наличия технического персонала на местах. Для ASA это нормальная реальность. Сложно себе представить удаленные офисы или КПК на MSSQL, работающие с консолидированной БД на Oracle. Для ASA это тоже нормальная реальность. Сложно себе представить бензоколонку у черта на куличках где то на трассе Москва-Мухосранск, где MSSQL собирает данные и посылает их в центр на консолидированную БД по ночам через GPRS. Для ASA это тоже нормальная реальность. Из чего можно сделать - продукт вполне конкурентноспособный и проекты сделанные на нем так же достаточно хорошо конкуретноспособны. Другое дело, что никто и нигде не проводит маркетинговых акций и реклам по популяции данного продукта, но смею уверить, ASA много где работает даже в России, причем в очень крупных и серьезных конторах, в том числе государственных (к сожалению раскрывать имена не могу, но уж прошу поверить мне на слово). Для меня это тоже достаточный повод ценить и использовать этот сервер. Ну а нет попсовости - да и слава богу, из за этого как минимум этот сервер развивается исключительно для своих групп пользователей и по их пожеланиям в ту сторону, которая выгодна для их бизнеса (естественно имеется ввиду зарубежные группы пользователей). К вопросу о фичах это действительно получается правильно, в функциональности появляется ровно то, что не хватает нам, разработчикам, а не только для того, чтобы толкнуть рекламу маркетинговым отделом.
9 окт 05, 21:27    [1952203]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

Сложно себе представить удаленные офисы или КПК на MSSQL, работающие с консолидированной БД на Oracle.

Ну мож и не очень сложно. Надо будет представим. Воображение то какое никакое есть еще пока:
[url=http://]http://www.interface.ru/oracle/OracleDB10g.htm[/url]
10 окт 05, 00:18    [1952284]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ChA
Member

Откуда: Москва
Сообщений: 11377
ASCRUS
Из чего можно сделать - продукт вполне конкурентноспособный и проекты сделанные на нем так же достаточно хорошо конкуретноспособны. Другое дело, что никто и нигде не проводит маркетинговых акций и реклам по популяции данного продукта, но смею уверить, ASA много где работает даже в России, причем в очень крупных и серьезных конторах, в том числе государственных (к сожалению раскрывать имена не могу, но уж прошу поверить мне на слово).
Да верю я Вам, верю, уважаемый. Ни одного слова худого не молвил про ASA, если Вы случайно не заметили, также, как и в адрес других представителей семейства серверных СУБД.
Верю и в пользу тех или иных фич, которые есть у любого из конкурентов MSSQL. И даже сожалею иногда, что нет иных в оном. Просто-напросто иногда раздражает потрясание подобными фичами, как будто без них и СУБД не СУБД, и проекты убогие, и разрабочики тупые, и пользователи недоумки...
Список можете продолжить на Ваше усмотрение :)

С уважением.

P.S. С моей стороны флейм закончен. Прошу прощения у всех, кого случайно зацепил в пылу полемики.
10 окт 05, 00:26    [1952291]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
alexey_tm
Member

Откуда: Томск
Сообщений: 173
StalkerS
alexey_tm

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

Это вы про mssql ?
тогда совершенно логично выглядит заявление "скажу, что фигня это полная ваш маздай"

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


Просмотрел форумы с Вашим участием, удручает... И вызывают сомнения Ваши заявления.
10 окт 05, 09:31    [1952566]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
[OffTop]
Первая пара выходных за 4 месяца - это прекрасно :)
Первый сезон Вавилона просмотрел
[/OffTop]

StalkerS

я-бы вот например, нашел другую работу. Это (особенно в Москве)
сложностей не представляет. Какой смысл напрягаться на работе, она радость должна приносить...


Во первых, в Казани это НЕСКОЛЬКО сложнее. Во вторых, кто Вам собственно сказал, что работа не доставляет мне радость ??? Не делайте поспешных выводов. В этом мире полно извращенцев

StalkerS
Я говорил про то, что реализовывать фичность надо с умом, а не тащить все подряд, как Плюшкин.


Мне НРАВИТСЯ как это делает Oracle. С Плюшкиным, поверьте это не имеет НИЧЕГО общего. То как о делает Microsoft, мне нравится МЕНЬШЕ, только и всего ;)

StalkerS
А вот если пойти по другому пути, и реализовать алгоритм Джо Селко, так он сделает и мой алгоритм и оракловую фичу одной левой. Так что, думайте, господа...


Подумал ... понравилось :) А что мне собственно мешает реализовать того-же Селко на Oracle ??? Подумайте ОБ ЭТОМ.

StalkerS

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


А Вы попробуйте их ЛЮБИТЬ, а не трахать (c) Не мой
10 окт 05, 10:39    [1952847]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
segun
ваши слова лишний раз говорят о вашей недалекости, уж извините такие мои слова. Вы не потрудились проверить мои мысли, а просто предпочли быстренько их отвергнуть. Тесты, реальные тесты, говорят о том что .Net иногда оказывается очень полезен. T-SQL идеально подходит для DML операций, но вот для циклов, сложных мат.расчетов, регулярных выражений он подходит гораздо меньше чем .Net.


Если Вы обратили на это внимание, я несколько раз говорил здесь, что если .Net на стороне MS SQL сервера приживется - то по ЕДИНСТВЕННОЙ причине, в силу УБОГОСТИ TSQL. Заметьте, я сказал то-же самое, просто другими словами

А за неглупого мужика, спасибо. Доброе слово - оно и кошке приятно :)
10 окт 05, 10:45    [1952891]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
yokon2005
Согласен с segun. Налицо осеннее обострение у ораклойдов, в предверьи выхода Yukon.
Более всего показательно, что обострения происходят у безграмотных ораклойдов.
Кто вам сказал, что .NET - это интерпретатор? Плюньте в того - он плохой советчик и не показывайте так открыто своего невежества в технологиях MS.
IL практически всегда компилируется в целевой машинный код, при этом эффективность кода очень и очень высока. Код .NET очень эфективен. Можете посмотреть результаты старых тестов.
Неверите - проверьте сами.


Прежде чем хамить, почитайте классиков
.Net это СРЕДА, а большая часть языков в нем такие-же псевдокомпиляторы как Perl и Java. Единственный честный компилятор в .Net С++, при производстве им unmanaged-кода.
10 окт 05, 11:12    [1953075]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
yukon2005
Советую вам написать хотябы одну и посмотреть, что представляет ее ассемблерный код. Видимо, вы будете сильно удивлены.


Возможно вас это удивит, но IL-ассемблер ЯВУ, до тех пор пока не изобретут для него IL-процессор.
10 окт 05, 11:13    [1953089]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
yukon2005
Gluk (Kazan)
P.S. Тенденции в развитии Oracle меня тоже не воодушевлют, но это отдельная тема, что касается MS SQL, лучше-бы он оставался честным блокировочником
Оговорка "по Фрейду". Именно этого и боятся ораклисты. По крайней мере, один мой знакомый ораклист из фирмы "Leaves" так и говорит, что их клиенты все чаще требуют MSSQL. А после того как mssql станет еще и версионником, у него останется еще меньше аргументов сманивать этих клиентов на оракл.


Вы уж для себя определитесь - версионность плохо или версионность хорошо, а то это сильно напоминает позицию разработчиков MySQL в отношении транзакций - "транзакции это зло, но в следующей версии мы их обязательно сделаем"
Если-бы в Юконе версионность была сделана нормально, а не через обычное для M$ место, я был-бы только рад :) Мне боятся нечего, работаю с тем что лучше продается
10 окт 05, 11:17    [1953121]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ЛП
Yo!!
а то что оракл занимает 51% российского рынка

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


Скоро это станет ВОЗМОЖНЫМ !!! БГ о Вас постоянно думает и заботится
10 окт 05, 11:19    [1953134]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

ChA wrote:
> locky
> нельзя, в результате чего можем иметь до 30% проигрыша по времени.
> Учитывая что если сделать delete то можно нарваться на эскалацию
> блокировок и прочие процессы будут курить... а так - у каждого -
> абсолютно личная таблица, никто никого не блокирует, удалять данные из
> них - просто блеск... кроме того, такие таблички чистятся САМИ при
> обрыве коннекта, а при MS SQL приходится чистить их ручками, как после
> расчета, так и до (на всякий случай).
>
> 30%, если правильно понимаю, взято с потолка, в лучшем случае, на основе
> частного случая. Делайте кластерный ключ со spid первым полем, и ни с
> кем конфликтовать не будете. И чистите всегда до, а не после. Впрочем,
> зачем мне это Вам обьяснять, полагаю, что Вы и сами это знаете. Могу
> согласиться, что в ASA с этим работать проще, но в то же время не
> чувствую себя обделенным благами, мне обычно редко чего не хватает,
> всегда можно сделать самому, слава Богу, есть на это время и желание.
нет, 30% - не с потолка, увы.... Да, и кластерный индекс у нас по SPID,
и чищу всегда до (потому как надо ведь, так что после можно и не чистить)...
Но согласитесь, truncate завсегда быстрее чем Delete. йето раз. Второе.
Когда имеем относительно небольшую вначале табличку, запросто можно
нарваться на то, что менеджер блокировок заблокирует её всю (так
дешевле), и остальные процессы будут ждать. Видено неоднократно.

> locky
> А вы попробуйте позаливать данные из внешних файлов.
>
> BULK оставляет только факт своего выполнения в логе, это-то Вы должны знать
Гы... дык ведь не всегда булк применим, тут уж увы... Иногда приходится
дополнительно обрабатывать данные, причем достаточно сложным образом...
процы юзать... всё такое....

> locky
> или посчитать большие отчеты с множеством промежуточных данных. там нах
> не нужны транзакции, но их, млин, поддерживают... опять таки - проигрышь
> по скорости...
>
> Тут мне сказать нечего, кроме того, что есть OLTP, где отчеты могут
> носить только простейший характер, и OLAP, где аналитики могут рыться
> как свиньи в желудях. Разный подход, разная актуальность и точность
> данных, и подходы к хранению данных - тоже разные. Стремление объединить
> вполне понятно, но, IMHO, либо танк, либо самолет, либо не то и не другое...
Да причем тут олап, прости господи, что-ж вы его кругом все тулите.
Понимаю, слово красивое и направление модное. Но посчитать сальдовку по
500К+ счетам это не поможет, не правда-ли?

> locky
> да потому что она одна на весь сервак!!!!
>
> И что ? Ну сделайте больше файлов, разнесите на разные диски, stripping,
> каналы, контроллеры. Делайте хоть что-нибудь, жаловаться на жизнь все
> могут. В конце концов убедите начальство, если сами к таким не
> относитесь, перейти на Oracle или ASA, вот оно счастье и наступит. Хотя
> у начальства другие приоритеты обычно :)
Гы, батенька... для того чтобы разносить всё на разное железо - на
железо надо денюжки, и немалые подчас. с другой стороны, в некоторых
продуктах (не будем тыкать пальцами) эти проблемы решаеются бесплатно
путем изменения настроек.
И потом... "Делайте хоть что нибудь!" Дык делаем, работа то должна
работать, какие бы проблемы у меня лично не возникали, не правда ли?
Просто хочется проще как-то, душевнее...
Перейти на чо-нить другое? Ну, знаю их куда хуже (знаю что они есть, но
как с йими работать...), потом, у них и своих проблем валом, если не
сказать больше... у меня ведь цель - не сбежать или охаять, а получить в
MS как можно более подходящий мне сервер.

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

10 окт 05, 11:43    [1953256]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
yokon2005
Guest
Gluk (Kazan)
Прежде чем хамить, почитайте классиков
.Net это СРЕДА, а большая часть языков в нем такие-же псевдокомпиляторы как Perl и Java. Единственный честный компилятор в .Net С++, при производстве им unmanaged-кода.

Часть абстратного кода целочисленных вычислений на C# и его так называемая "псевдокомпиляция":
  k = ++i * j + i % j;
00000028  inc edi  
00000029  mov eax,edi 
0000002b  cdq             
0000002c  idiv eax,dword ptr [ebp-10h] 
0000002f  mov eax,dword ptr [ebp-10h] 
00000032  imul eax,edi 
00000035  add edx,eax 
00000037  mov dword ptr [ebp-14h],edx 

Хотелось бы спросить, что вы вообще считаете честной компиляцией?

Вместо того, чтобы сылаться на умных дядек, проверьте лучше сами.
10 окт 05, 12:54    [1953662]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Единовременную компиляцию приложения в исполняемый модуль.
Если не улавливаете разницу, разговаривать не о чем.
10 окт 05, 13:12    [1953756]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
DarkSquid
Member

Откуда: http://terredesreves.3bb.ru/
Сообщений: 4882
Gluk (Kazan)
Единовременную компиляцию приложения в исполняемый модуль.
Если не улавливаете разницу, разговаривать не о чем.


JIT компиляция непосредственно на машине, на которой код выполняется обладает преимуществом возможности оптимизаций под конкретный процессор. В итоге конечный машинный код, в общем случае, получается более оптимальным при использовании JIT компилятора, нежели при компиляции в расчёте на самую слабую машину.
10 окт 05, 13:28    [1953837]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
yokon2005
Guest
Gluk (Kazan)
Единовременную компиляцию приложения в исполняемый модуль. Если не улавливаете разницу, разговаривать не о чем.
По вашему, если эта компиляция будет проходить через промежуточный IL код, несмотря на то, что в результате, я все равно получу эфективный машинный код под данный процессор, то это уже не компиляция - а так - "интерпретатор".
Для вашего сведения, .NET - это не "виртуальная машина", а среда выполнения.
С таким же успехом вы можете назвать VCL - "виртуальной машиной" для выполнения "интерпретируемого кода", порождаемого Delphi - компилятором.
А екстраполируя ваши рассуждения дальше, получается, что и Win32 - это "виртуальная машина Windows" для выполнения интерпретируемого процессором машинного кода.

Да, разговаривать действительно мало о чем.
10 окт 05, 13:38    [1953893]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
DarkSquid
Gluk (Kazan)
Единовременную компиляцию приложения в исполняемый модуль.
Если не улавливаете разницу, разговаривать не о чем.


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


В последний раз (надоело уже) Java точно такой-же JIT компилятор, правда в отличии от .Net действительно кроссплатформенный. Если термин (компилятор) применяется, его следует применять строго.

Строго говоря, языки платформы .Net, за исключением C++ НЕ КОМПИЛЯТОРЫ

И закончим на этом
10 окт 05, 13:46    [1953938]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
DarkSquid
Member

Откуда: http://terredesreves.3bb.ru/
Сообщений: 4882
Gluk (Kazan)
В последний раз (надоело уже) Java точно такой-же JIT компилятор, правда в отличии от .Net действительно кроссплатформенный.


Согласен. Ну и что? (что-то я пропустил не 12 страницах, видимо...) Работает, скомпилённый код, кстати ни чуть не медленнее чем код на C++. Единственный глюк - сборка мусора неэффективно производится. А так - всё быстро, разумно и удобно.

Gluk (Kazan)
И закончим на этом


Как пожелаете.
10 окт 05, 13:50    [1953966]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
yokon2005
Guest
Gluk (Kazan)
Строго говоря, языки платформы .Net, за исключением C++ НЕ КОМПИЛЯТОРЫ
И закончим на этом
По величайшему повелению Gluk (Kazan), отныне все обязаны называть эти языки "интерпретаторами".
Все поняли!!!
Они не укладываются в понятие "строгого" компилялятора потому что производят промежуточный код на неком абстрактном ассемблере, которым является IL.
Несмотря на то, что в результате перед первым выполнением, такой программы, вы все равно получите машинный код - требую не верить своим глазам.
Отныне называть .NET Framework - "виртуальной машиной", занимающейся нелегким делом интерпретации машинного кода для запуска библиотек.

Так велел, великий и мудрый Gluk из Казани.

И закончим на этом!!! И чтоб цыц у меня!!!
10 окт 05, 13:59    [1954008]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
автор
Отныне называть .NET Framework - "виртуальной машиной", занимающейся нелегким делом интерпретации машинного кода для запуска библиотек.


А что разьве это не так ???

До чего-же некоторые люди бывают смешными :)
10 окт 05, 14:17    [1954107]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Dooma
Guest
Gluk (Kazan)
Строго говоря, языки платформы .Net, за исключением C++ НЕ КОМПИЛЯТОРЫ
На сколько я понимаю, спор идет о возможности применения термина "интерпретатор" к java или С#. Так строго говоря, это неверно.
Интерпретатором в какой-то степени можно назвать виртуальную машину java.
PL/SQL, T-SQL - это интерпретаторы. Но если откомпилировать тот же PL/SQL в машинный код - то результат уже интерпретироваться не будет.
Точно так же и с IL для NET. В конечном результате имеем тот же EXE-шник в машинных кодах, выполнение которого не подходит под определение интерпретатора. Больше подходит на определение компилятора из IL.
10 окт 05, 15:14    [1954460]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 [12] 13 14 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить