Мастер, вообщет этот вопрос был касательно eval а. и "невозможности" сделать это на си.
На си можно написать (и они уже написаны) движки, которые будут интерпретировать любой скриптовый язык.


Ничто не мешает gcj, а компилировать на лету затем, чтобы можно было запустить один и тот же "набор байтов" под любой платформой (скриптовая фишка) и увеличить скорость выполнения посравнению с "прямой" интерпретацией байт-кода.


Это сообщение отредактировал(а) Alexandr87 - 4.6.2008, 09:53

както тихо тут стало...
 

Давайте про D пофлеймим. 

D рулит. Миксины форева. 

Dtrace наше фсио, а без D в него не суйся!

Согласен D рулез, одни итераторы чего там стоят 

Кстати а есть нормальные IDE для D?

vim.

Добавлено через 28 секунд
      

А зачем тогда D рекламится левыми способами?
Там была таблица сравнения с C/C++/Java/C#, так там куча пунктов неверно была проставлена: типа в D оно есть, а в других нету, хотя на самом деле в других это тоже есть.

Mayk, я спрашивал про нормальную IDE, а не как бы мне поизвращенней убить свое время  

Code::Blocks, Poseidon, Eclipse... как грязи  

Я про это ничего не слышал, да... и не интересно. Зачем всё это? Можно пытаться распаралелить фортран, и на телегу можно поставить колёса от автомобиля. Наверно, в этом есть какойто смысл. Но я его не вижу.
  (Не понял я.)
Докомпилировать байт код имеет смысл при инсталляции ПО на Java  написанного именно для того, чтоб увеличить скорость выполнения кода. К переносимости на другие платформы это не имеет никагого отношения. Вы же не переносите установленный Офис на новый компьютер. Вы туда ставите дистрибутив.
Так вот, дистрибутив пусть содержит только байткод. Натив код из него можно сгенерить при инсталляции ПО на конкретную железку.
С апплетом этого сделать нельзя, а мы и небудем.

Это сообщение отредактировал(а) Мастер - 5.6.2008, 14:21

Шумит меньше и ездит "мягче"  
А фортран паралелить не нужно, его перпендикулярить нужно  

   про это не надо слышать. Это надо понимать - это принцип. 



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

А в чём проблема? Уже много лет существует OpenMP технология для фортрана.

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

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

Распаралеливать Фортран глупо. Можно было просто создать библиотеку(DLL) и подключить её к Java.
Но есть и серьёзный недостаток - интерпретаторы медленные. Поэтому докомпиляция кода может ускорить его.

Это сообщение отредактировал(а) Мастер - 6.6.2008, 06:21