Будущее за виртуализацией?

[Mirror]

Если насчет С и С++ я согласен, т.к. С/С++ был всегда компромиссом, таким универсальным комбайном, в котором можно было сделать все, но хорошо сделать было практически невозможно (только великие гении могут делать качественный код на С и С++). У паскаля наоборот все намного лучше. И Java и C# - это все было способом устранить недостатки языка С++, которых изначально не было в паскале.

Мне кажется, не стоит путать Си и C++. Си никогда толком не был «универсальным комбайном», он по-своему элегантный (хотя препроцессор в Си некрасивый, конечно). Но Си ниже по уровню, чем Паскаль.

А вот плюсы — комбайн на все случаи жизни, да.

[dedm0zaj]

А она уже частично виртуальная.

частично

[alexey38]

Си никогда толком не был «универсальным комбайном», он по-своему элегантный (хотя препроцессор в Си некрасивый, конечно). Но Си ниже по уровню, чем Паскаль.

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

Безымянный2.png

Функционально реальные компиляторы паскаля позволяли делать по сути все то же самое, что мог делать язык "С". Хотя базовый виртовский паскаль он многого не умел, но уже в турбо паскале все было, что нужно было для всяких там хакерских штучек. 20 лет назад я 75% кода писал на ассемблере (графика, базы данных и т.п.), а 25% писал на паскале, там где нужна была сложная бизнес-логика. Язык "С" знал хорошо, но мы его считали достаточно отстойным, т.к. он не давал нам ничего того, что мы умели делать на паскале или асме. При этом паскаль быстро компилился, а "С" вытормаживал. И самое главное, что все тесты, которые мы тогда делали, то проги на турбо паскале работали раза в два быстрее, чем код на "С".

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

[absdjfh]

Сколько знаю людей, разговоры про низость или высость языков поднимаю те, кто не имеет опыта написания низкоуровневых программ.

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

Язык Си объединяет черты языка высокого и низкого уровня, и в то же время машинно-независим в отличие, например, от Ассемблера

[offtop]
Высость? Нет, это, конечно, логичный антоним слову "низость", и все же это слово как-то устарело
[/offtop]

[alexey38]

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

Когда я пишу отчеты и доклады, то я тоже многое чего пафосного туда пишу.

Но если по сути вопроса, что в языке "С" есть конкретно такого, чего нет у паскаля (turbo pascal, borland pascal, freepascal, Delphi), что делало бы язык "С" хотя бы немного более низкоуровневым языком, чем паскаль?

Интересует именно конкретика, т.к. 25 лет назад, когда я только начал изучать программирование, то одновременно изучил оба языка. Многие вещи специально писал на обоих языках, чтобы их сравнить. И я тоже читал книги, где писалось про низкоуровневые возможности языка "С", но я те же самые низкоуровневые штучки делал для сравнения и на паскале. Поняв, что языки позволяют делать одно и тоже, а что они не умеют делать, то я умел писать на асме, то я сам для себя провел тестирование на скорость исполнения, размеры файлов и т.п. У меня был Турбо паскаль, был Тубро С, и микрософтовский С, и уменя паскаль вышел победителем. После чего весь основной софт писал только на паскале. А на С/С++ писал только то, что кем-то уже было начато на Сях, либо если заказчик требовал писать именно на Сях для интеграции в большой проект.

Добавлено спустя 3 минуты 9 секунд:
Нашел описалово про ООП и ассемблер: http://citforum.ru/programming/tasm3/tasm3_4.shtml
20 лет назад я это освоил, и успешно применял ООП на асме.

[vada]

alexey38
Глубочайшее заблуждение

и далее байт-код интерпретируется при исполнении

Это все закончилось еще во времена JAVA 1.2 На дворе JAVA 1.7. Сейчас байт код JAD-ом оптимизируется и превращается в нативный код который и выполняется на процессоре. Причем, уровень оптимизации JAD-ом не достижим оптимизаторами ни С ни С++ ни каким-либо другим компилятором в нативный код.
Так что хватит повторять чужие глупости про медленную яву.

Добавлено спустя 12 минут 23 секунды:
Не ну ржунемагу

Для решения таких простецких задач широко применялась и применяется ява

alexey38 Вы, видимо, не в курсе что JAVA это корпоративный рынок. Это приложения масштаба предприятия, и альтернативы пока нет. M$ пытается со своим .NET влезть, но поезд давно ушёл.

[alexey38]

Это все закончилось еще во времена JAVA 1.2 На дворе JAVA 1.7. Сейчас байт код JAD-ом оптимизируется и превращается в нативный код который и выполняется на процессоре. Причем, уровень оптимизации JAD-ом не достижим оптимизаторами ни С ни С++ ни каким-либо другим компилятором в нативный код. Так что хватит повторять чужие глупости про медленную яву.

Для начала нужно не забывать, что любой код, в т.ч. интерпретируемый исполняется на процессоре. Во-вторых, Ява бывает и в скриптах, и в байт-коде. При первом исполнении на конкретном компе JAD или .NET как бы компилируется в машинный код (то что называют сейчас модным словом нативным). Но при этом ни в яве ни в нете нет полного исключения интерпретации самого кода. Интерпретация заключается в наличии виртуальной машины. Смысл интерпретации не в том, что в реальном времени некий интерпретатор переваривает текст команды или ее байт-код. Смысл интерпретации в том, что исполнение команды зависит не только от текста этой команды, но и от ряда внешних по отношению к этой команде вещей. Возникает вариативность кода, в зависимости от результатов некого иного кода.

Поэтому не нужно путать компиляцию на стороне пользователя, с той же самой JVM. Есть отличия, и это сделано осознанно и специально, т.к. для ряда применений это есть хорошо, но для других применений это будет плохо.

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

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

Добавлено спустя 37 секунд:

Не ну ржунемагу

А я над Вами.

Добавлено спустя 8 минут:

alexey38 Вы, видимо, не в курсе что JAVA это корпоративный рынок. Это приложения масштаба предприятия, и альтернативы пока нет. M$ пытается со своим .NET влезть, но поезд давно ушёл.

Я говоря про простецкие задачи, говорю как раз про корпоративный рынок приложений с БИЗНЕС-ЛОГИКОЙ. Особенность таких задач состоит в том, что алгоритмически они разделяются на достаточно простые типовые функциональные блоки, связанные между собой тоже достаточно простыми логическими и математическими связями. Условно говоря общий алгоритм работы бизнес-приложения сможет рассказать любой высококвалифицированный юзер, а внутренность (если написано в хорошем стиле), то будет понятна программисту сходу. И для этих целей Ява - отличный инструмент.

[SSerge]

Но если по сути вопроса, что в языке "С" есть конкретно такого, чего нет у паскаля (turbo pascal, borland pascal, freepascal, Delphi), что делало бы язык "С" хотя бы немного более низкоуровневым языком, чем паскаль?

Здрасьте... В отличие от паскаля, у Си абсолютно всё I/O отделено от языка как такового, равно как и некоторые типы данных, с которыми оперирует Си, языку как таковому, не принадлежат. Что дает (давало) возможности (не теоретические, а сугубо практические), писать на нем программы для устройств, вообще не имеющих операционных систем. В свое время были такие аналоги IBM PC, которые грузились с магнитофона, например. На Си для них можно было кое-что написать, выполняя определенные правила; любая же версия турбо-борланд-и прочих паскалей и фортранов оказывалась в безусловном ауте, ибо не может существовать без своего рунтайма, железно зависимого от операционной системы

[alexey38]

Здрасьте... В отличие от паскаля, у Си абсолютно всё I/O отделено от языка как такового, равно как и некоторые типы данных, с которыми оперирует Си, языку как таковому, не принадлежат. Что дает (давало) возможности (не теоретические, а сугубо практические), писать на нем программы для устройств, вообще не имеющих операционных систем. В свое время были такие аналоги IBM PC, которые грузились с магнитофона, например. На Си для них можно было кое-что написать, выполняя определенные правила; любая же версия турбо-борланд-и прочих паскалей и фортранов оказывалась в безусловном ауте, ибо не может существовать без своего рунтайма, железно зависимого от операционной системы

Если Вы запишите версию Visual C или другую известную версию для Винды на магнитофон, то она не будет работать на компах, которые грузились с магнитофона. Вы мне говорите то же самое, что если Тубро или Фрии Паскаль записать на магнитофон, то эта версия не заработает на тех старых ЭВМ. Ясно, что не заработает, сделайте вначале версию для той ЭВМ, тогда и заработает.

Наличие встроенного оператора Read, Write, Assign, Reset, Rewrite и т.п. не является признаком того, что на паскале нельзя ничего написать. Использовать данные команды никто не заставляет. Для конкретной реализации ЭВМ, в зависимости от наличия или отсутствия ОС, команда Assign может разрешать или запрещать определенные виды имен файлов. Если у Вас есть из накопителя только магнитофон, то делайте реализацию IO именно для магнитофона, язык не запрещает это делать.

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

[SSerge]

Если Вы запишите версию Visual C или другую известную версию для Винды на магнитофон

Узнаю профессиональный троллизм Я говорил о том, что ни одним паскалем тех времен (среда DOS, ёпта) (и нынешних) невозможно сгенерировать программу, способную работать на компьютере без операционной системы ввиду определенных зависимостей, обязательных для функционирования такой программы, а Си это вполне позволял делать.

Наличие встроенного оператора Read, Write, Assign, Reset, Rewrite и т.п. не является признаком того,

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

Поэтому, резюмируя ваши аргументы, alexey38, вы занимаетесь демагогией

Добавлено спустя 17 минут 52 секунды:

Для конкретной реализации ЭВМ, в зависимости от наличия или отсутствия ОС, команда Assign может разрешать или запрещать определенные виды имен файлов.

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

[SeZuka]

а Си это вполне позволял делать

А чем паскаль то не позволял?

[SSerge]

А чем паскаль то не позволял?

У него в инициализации неисключаемого модуля system, а то и в префиксном коде, дописываемым самим компилятором, огромное количество обращений на функции DOS (int 21h) - типа проверки таймеров, версии ОС, установки дескрипторов потоков и прочего, а самое главное - запросы выделения памяти средствами ОС. Это обойти невозможно, без наличия DOS или ее имитации.

[alexey38]

Узнаю профессиональный троллизм Я говорил о том, что ни одним паскалем тех времен (среда DOS, ёпта) (и нынешних) невозможно сгенерировать программу, способную работать на компьютере без операционной системы ввиду определенных зависимостей, обязательных для функционирования такой программы, а Си это вполне позволял делать.

Профессионально троллите как раз Вы. Вы утверждаете, что недостатком Паскаля, как языка, является то, что конкретный компилятор паскаля (Трубо Паскаль) для DOS, не мог создавать исполняемый образ для компа без DOS. Это обычное забалтывание темы не по существу вопроса. Вы или кому это надо, могли и можете написать версию компилятора паскаль, например, на базе FPC, чтобы создавался образ для загрузки без ОС. Это функции линковщика и компилятора, возможности языка тут не при чем, и не надо говорить всякий бред. Тем более сейчас иметь на любых устройства ОС - это норма. И речь в данной теме форума идет не о том, что нужно создавать программы для работы без ОС, Вы вообще уводите вопрос в область никому не нужной фантазии.

Добавлено спустя 11 минут 8 секунд:

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

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

К слову сказать, что компов совсем без ОС не бывает. В компах, которые загружались с магнитофона, в качестве базовой ОС выступала ПЗУ. В современных комах базовой ОС является BIOS, который и есть по существу минимальный вариант ОС. Реализовать в паскале ввод-вывод используя BIOS не проблема, собственно в начале 90-х именно так и делали.

Добавлено спустя 6 минут 2 секунды:

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

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

[SSerge]

речь в данной теме форума

Вы тут начали гнуть пальцы, что Си типа исключительно язык высокого уровня, причем низкоуровневые возможности у него абсолютно те же что и паскаля. На что я вам возразил, вспомните: у Си библиотеки ввода-вывода всегда отделены от самого языка как такового, в отличие от паскаля. Если не доходит до вашего просвещенного мозга до сих пор - напишите какой нибудь текст без USES на паскале, и сделайте то же самое на Си, не используя #include системных библиотек. После чего сравните, где чего больше возможно. Как ни странно, в паскале будет почти всё доступно, в отличие от Си. У какого из них выше уровень, а? Вы же даже не пытаетесь разделить, что может сам язык, а что делают его стандартные библиотеки.

[alexey38]

У него в инициализации неисключаемого модуля system, а то и в префиксном коде, дописываемым самим компилятором, огромное количество обращений на функции DOS (int 21h) - типа проверки таймеров, версии ОС, установки дескрипторов потоков и прочего, а самое главное - запросы выделения памяти средствами ОС. Это обойти невозможно, без наличия DOS или ее имитации.

Так потому, что Вы говорите о конкретной реализации компилятора паскаль для создания EXE-файлов для DOS. Например, компилятор языка Си и линковщик для Линуха не может создать исполняемый файл для DOS, Windows, OS/2 и т.п. Обращение к функциям DOS (через прерывание int 21h) не является аксиомой самого языка Паскаль. Я уверен, что когда FPC компилится для Линуха, Андроида, Mac OS, Windows, то данные прерывания вообще не используются. Компилятор FPC один, но он уже много лет, как умеет создавать исполняемые файлы для разных вариаций ОС, и никогда не было проблемы сделать вариант еще для одной платформы.

Если Вы не понимаете сути вопроса, то для чего встреваете в разговор с безграмотными утверждениями. Форум читают и новичики, для чего Вы для них осознанно даете дезинформацию. Я понимаю, что Вы бредите, а другие это же не поймут.

Добавлено спустя 6 минут 51 секунду:

Вы тут начали гнуть пальцы, что Си типа исключительно язык высокого уровня, причем низкоуровневые возможности у него абсолютно те же что и паскаля. На что я вам возразил, вспомните: у Си библиотеки ввода-вывода всегда отделены от самого языка как такового, в отличие от паскаля. Если не доходит до вашего просвещенного мозга до сих пор - напишите какой нибудь текст без USES на паскале, и сделайте то же самое на Си, не используя #include системных библиотек. После чего сравните, где чего больше возможно. Как ни странно, в паскале будет почти всё доступно, в отличие от Си. У какого из них выше уровень, а? Вы же даже не пытаетесь разделить, что может сам язык, а что делают его стандартные библиотеки.

Какая разница, что доступно по умолчанию? Вы совсем не понимаете структуру языка Паскаль? Открывайте учебник для новичков и учите. Вы банально забываете, что в Паскале по умолчанию включен оператор "USES System", но у Вас есть возможность на самом паскале написать реализацию модуля System, используя операторы условной компиляции. Именно так, а не по другому работает FPC, где модуль System написан на паскале, а не на Си. Не нужно путать магию и Ваше собственное незнание вопроса. В компиляторах Паскаля не предназначенных для кроссплатформенной компиляции, таких как Турбо Паскаль, не было возможности изменять модуль System, но это возможности конкретной реализации конкретного компилятора.

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