Сообщение от Evg Нет. Главное то, что в одном случае для запуска программы не требуется ничего дополнительного, а в другом случае - дополнительная программа-запускалка. Сыр-бор по этой части начался с того, что ты не согласился с тем, что я запуск приложений .net назвал интерпретацией. Я тебе объяснил, почему Ога. А ещё нужно чтобы компутер был. А ещё - чтобы в розетку было включено. А ещё - чтобы чубайс в розетку подал напряжение. Правда чубайс уже этим не занимается, но не суть.

Если код в конце концов исполняется непосредственно процессором, это не интерпретация.

Сообщение от Evg Опять-таки это всё Windows (пусть и Mobile). Так что у .net пока нет реальной многоплатформенности, какая есть у java или qt

Чем тебя mono не устраивает?

0

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

0

Сообщение от Vourhey о если делать что-либо связанное с БД, то дельфя тут сразу выйдет в перед по простоте и скорости ввиду наличия большого кол-ва готовых компонентов заточенных для работы с различными БД.

Писали тут одни пока не пришел и не растыкал компоненты и не врубил связи между ними - два часа слушал через стенку как они спорили почему не работает

0

Сообщение от Alligieri Писали тут одни пока не пришел и не растыкал компоненты и не врубил связи между ними - два часа слушал через стенку как они спорили почему не работает

Не, ну руки прямые тоже должны к программисту прилагаться, само собой а то и на ассемблере напишешь быстрее )))

0

Сообщение от HIMen У меня amd и помню, пользовался wineом

Говоря про Intel, я имею в виду Intel'овскую систему команд (которую AMD поддерживает), а не наклейку "Сделано компанией Intel". Либо ты этого действительно не понимаешь, либо придираешься к словам

Сообщение от iama Evg, действительно, вайн не только кроссплатформенное, н и аппаратно независимое ПО.

В первом же предложении по твоей ссылке: "... систем архитектуры x86 (и других архитектур, при наличии совместимости, например, AMD64)". Где ж тут платформо-независимое?

Сообщение от NightmareZ Если код в конце концов исполняется непосредственно процессором, это не интерпретация.

Пипец... а при интерпретации код по твоему кем исполняется? Видеокартой что ли?

Сообщение от NightmareZ Чем тебя mono не устраивает?

Это самоделка, которая далеко отстала от жизни. Правда мне казалось, что там только под Intel'ом работает, однако на сайте можно выбрать sparc-solaris. Других архитектур не наблюл, но тем не менее по части кроссплатформенности беру свои слова назад: mono можно условно назвать кроссплатформенной. Тем не менее внятных решений на современном уровне по части Framework, судя по всему, нет. В то время как java изначально работало на всём и всегда на всех архитектурах можно было нормально работать на последней версии. Потому что идея, которую изначально заложили в java, действительно была кроссплатформенным решением. И не только на бумаге, но и в реализации

0

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

Жаль "+1" нельзя нажать

0

Сообщение от Evg Пипец... а при интерпретации код по твоему кем исполняется? Видеокартой что ли?

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

Добавлено через 1 минуту

Сообщение от Evg Это самоделка, которая далеко отстала от жизни.

Чем отстала?

0

Сообщение от NightmareZ Кодом, который в свою очередь исполняется процессором. Уровень абстракции другой.

Какая разница какой уровень абстракции? Изначально речь пошла о том, что интерпретация принципиально от JIT-компиляции не отличается. Какая в пень разница, исполняются коды интерпретатора или коды framework'а?

Сообщение от NightmareZ Чем отстала?

До недавнего времени на ней только 2.0 было. Как сейчас - не знаю. Но не думаю, что сильно что-то улцчшилось

0

Сообщение от Evg Какая разница какой уровень абстракции? Изначально речь пошла о том, что интерпретация принципиально от JIT-компиляции не отличается. Какая в пень разница, исполняются коды интерпретатора или коды framework'а?

Ну тогда с таким же успехом можно сказать, что компиляция от интерпретации ничем принципиально не отличается.

Сообщение от Evg До недавнего времени на ней только 2.0 было. Как сейчас - не знаю. Но не думаю, что сильно что-то улцчшилось

2.0 - это мало?

0

Сообщение от NightmareZ Ну тогда с таким же успехом можно сказать, что компиляция от интерпретации ничем принципиально не отличается.

Принципиально отличается тем, что для исполнения скомпилированного кода НЕ требуется дополнительных программ (интерпретаторов или framework'ов). Скомпилированный код напрямую исполняется на процессоре, а не требует преобразования некого промежуточного кода в машинный. Именно поэтому драйвер можно написать только на компилируемом языке. Говоря "можно" я понимаю, что теоретически можно извернуться и написать систему, которая бы поддерживала возможность написания драйвера на интерпретируемом языке и т.п. Но такие теоретические решения "из принципа" я не беру во внимание, потому что они не будут жить в реальном мире

Сообщение от NightmareZ 2.0 - это мало?

Это отставание на несколько лет, говорящее о тухлости концепции переносимого кода, реализуемого по системе "байт-код + библиотеки в нэйтив кодах". В противовес java'вскому "чистому байткоду", который хоть и не такой быстрый, зато является настоящим кроссплатформенным решением

0

Сообщение от Evg Принципиально отличается тем, что для исполнения скомпилированного кода НЕ требуется дополнительных программ (интерпретаторов или framework'ов). Скомпилированный код напрямую исполняется на процессоре, а не требует преобразования некого промежуточного кода в машинный. Именно поэтому драйвер можно написать только на компилируемом языке. Говоря "можно" я понимаю, что теоретически можно извернуться и написать систему, которая бы поддерживала возможность написания драйвера на интерпретируемом языке и т.п. Но такие теоретические решения "из принципа" я не беру во внимание, потому что они не будут жить в реальном мире

Ну вот, а в дотНете, программа сначала компилируется в MSIL, а затем компилируется в машинный код, который и исполняется.

Интерпретируемая же программа не компилируется в машинный код.

Сообщение от Evg Это отставание на несколько лет, говорящее о тухлости концепции переносимого кода, реализуемого по системе "байт-код + библиотеки в нэйтив кодах". В противовес java'вскому "чистому байткоду", который хоть и не такой быстрый, зато является настоящим кроссплатформенным решением

Так никто вроде и не собирался особо кроссплатформанным делать дотНет. К тому же в яве тоже библиотеки в нейтив кодах - как иначе то?

0

Сообщение от NightmareZ Ну вот, а в дотНете, программа сначала компилируется в MSIL, а затем компилируется в машинный код, который и исполняется. Интерпретируемая же программа не компилируется в машинный код.

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

Пока писал эту мысль, понял ещё один момент недопонимания. Говоря об интерпретаторе я всегда имел в виду интерпретатор языка программирования (типа perl, php и т.п.). А ты по ходу дела говорил об интерпретаторе байт-кода (как в случае java)

Сообщение от NightmareZ Так никто вроде и не собирался особо кроссплатформанным делать дотНет.

Где-то тут мелькала мысль, что одним из достоинств .net является кроссплатформенность

Сообщение от NightmareZ К тому же в яве тоже библиотеки в нейтив кодах - как иначе то?

Нет. В jave библиотеки написаны на джаве. Именно это и лежит в основе всей технологии и именно благодаря этому джава кроссплатформенна не только в теории, но и на практике. Кстати, вспомнил, что я про это уже писал Заезженный вопрос-какой язык выбрать!!!

0

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

Основное время будет занимать выполнение машинного кода, и лишь по мере необходимости те куски, которые ещё не откомпилированы в него, будут компилироваться. Можно обработать сборку ngen'ом (например, во время инсталляции приложения) и тогда никакой JIT-компиляции не будет, программа будет в машинных кодах. Никакой интерпретацией тут и не пахнет.

Сообщение от Evg Пока писал эту мысль, понял ещё один момент недопонимания. Говоря об интерпретаторе я всегда имел в виду интерпретатор языка программирования (типа perl, php и т.п.). А ты по ходу дела говорил об интерпретаторе байт-кода (как в случае java)

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

Сообщение от Evg Где-то тут мелькала мысль, что одним из достоинств .net является кроссплатформенность

Ну да, дотНет менее кроссплатформенный, чем java. Не беда, не все красноглязят под линуксаме.

....на дотНете можно писать и для десктопа, и для серверов, и для браузеров (Solverlight), и для КПК и телефонов, и даже для контроллеров.

Сообщение от Evg Нет. В jave библиотеки написаны на джаве.

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

0

Самый универсальный это Python.

0

Сообщение от Fire55 Самый универсальный это Python.

Спасибо....

0

Сообщение от Fire55 Самый универсальный это Python.

хм... а если подумать - это так) только не думаю, что это самый универсальный, но универсальный
на Python можно писать визуальные приложения
можно писать сайты
скрипты под различные страницы

0

Сообщение от Vladiator хм... а если подумать - это так

Плохо думаешь.

0

NightmareZ, хорош без аргументов отвечать...

0

Сообщение от NightmareZ на дотНете можно писать и для десктопа, и для серверов, и для браузеров (Solverlight), и для КПК и телефонов, и даже для контроллеров.

Для портативных устройств, но только под управлением WinMobile, на Java же можно писать и под обычные телефоны. А так на Java все это тоже можно написать

0

Сообщение от NightmareZ Основное время будет занимать выполнение машинного кода, и лишь по мере необходимости те куски, которые ещё не откомпилированы в него, будут компилироваться. Можно обработать сборку ngen'ом (например, во время инсталляции приложения) и тогда никакой JIT-компиляции не будет, программа будет в машинных кодах. Никакой интерпретацией тут и не пахнет.

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

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

В случае с .net'ом вышеописанный онанизм предназначен для тех же целей переносимости, только в более узких масштабах. Речь идёт НЕ о переносимости между разными архитектурами, а о переносимости между разными версиями Windows (ну а со временем туда ещё и макос подцепилось). И именно ради того, чтобы один и тот же бинарник одинаково работал на разных версиях винды, микрософтеры так активно двигают эту технологию. Причём двигают не ради пользователей, а ради разработчиков. А точнее ради того, чтобы разработчики пересели на разработку под .net вместо нэйтив кода. Когда доля .net'овских приложений станет ощутимо большой, то у микрософтеров постепенно начнут развязываться руки в части разработки самой винды, потому что им больше не придётся заниматься таким мазохизмом, как длительная поддержка совместимости со старыми версиями винды. Эту проблему будет решать фрэймворк. И именно поэтому инструменты для разработки под .net являются куда более удобными, чем инструменты для разработки нэйтив кода. Это не заслуга языка C# и не заслуга .net как платформы. Это политика партии, связанная с геморройностью длительной поддержки всей линейки операционных систем в совместимом состоянии.

Сообщение от NightmareZ В дотНете нет интерпретатора байт-кода. Есть компилятор в байт-код и есть компилятор из байт-кода в машинный код.

Он есть в джаве. Правда я всё это сказал к тому, что мне наконец стала понятна одна из причин того, что мы постоянно крутимся вокруг одного и того же

Сообщение от NightmareZ ....на дотНете можно писать и для десктопа, и для серверов, и для браузеров (Solverlight), и для КПК и телефонов, и даже для контроллеров.

Тем не менее областью применения языков, ориентированных на .net остаётся класс прикладных приложений (это к вопросу об универсальности)

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

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

Добавлено через 1 минуту

Сообщение от Vladiator на Python можно писать визуальные приложения можно писать сайты скрипты под различные страницы

Всё это можно написать и на си и на паскале. Только вот на си в нагрузку можно написать драйвер или ос, а на питоне как-то не получится

0