Извини, но я не пойму, по какой логике они должны быть смешаны. Мы так же смешиваем и язык игры ил2 (с любым языком, на котором ты предлагаешь писать) и ничего криминального при этом не происходит? При том что параллельно работать могут еще с десяток разых программ. Зачем нам встраивать их друг в друга?Сообщение от Baks
Смотри. Смешение языка ИЛ-2 требует написание парсера/командера. Понимаешь ? Ява с дотнетом не МОГУТ обмениваться обьектами/вызовами. Они могут обмениваться только упаковаными в тот или иной вид пакетами чистых данных через некие туннели (TCP, Файлы, пайпы, ...) В результате, чтоб поженить яву с дотнетом надо на одной стороне писать паковщик данных, на другой распаковщик, и еще и реализовывать канал передачи данных. Все эти задачи не менее сложные и трудоемкие, чем собственно парсиг ила в чистом виде. Поэтому вязать яву и дотнет нецелесообразно - чем городить танспорт и систему вызовов проще написать свой командер.
А чтоб возможен был обмен ОБЬЕКТАМИ и вызовами, надо чтоб в ЕХЕ исполняемый, написанный на одном языке, был ВСТРОЕН модуль написанный на другом языке. Вот тут и вылазит скрипт, так как встраиваемые скриты позволяют а) не думать о сложностях ООП основоного языка и б) получить доступ к НУТРУ командера, манипулировать обьектами и вызовами.
Поэтому вот пожеить яву и C# не выйдет НИКАК, а вот их с каким нибудь скриптом - запросто.
И вот тут вылазит еще один нюанс. Если у нас есть группа, в которой ядро пишет архитектор, а обвязку народ на подхвате, то тут возможен вариант со скриптами. Так как в этом случае уровень "народа" может быть ниже сильно. Не надо знать всяких премудростей. НО! если у нас на все один-двое, то им проще все фигачить на одном "тяжелом" языке, так как это и быстрее и багов меньше и писать проще и отлаживать и ... вобщем одни плюсы.
Если ты веришь, что все можно испортить, поверь и в то, что все можно исправить. Раби Нахман из Браслава.
tahorg уже написал все правильно, но я хочу проиллюстрировать простым примером.
Рассмотрим ситуацию: Игрок дал команду <planes.
Раздельная реализация: парсер на Java (П), контроллер миссий на C# (К) и логика на Питоне (Л).
1. П видит команду <planes, и должен спросить К о наличии самолетов
2. Каким-то образом опрелелят где находится К
3. Устанавливает канал обмена информацией с К
4. Упаковывает данные: имя команды,имя игрока, координаты... возможно еще что-то
5. Передает К
6. К распаковывает
7. Производит вычисления и определяет наличие самолетов на данном поле.
8. Запаковывает запрос к Л на определение возможности взлета данному игроку на каждом из самолетов.
9. Передает Л
10. Л анализирует
11. Упаковывает обратно отфильтрованный список
12. K принимает ответ
13. Упаковывает для ответа П
14. П распаковывает ответ
15. П форматирует, переводит в локаль пользователя и выплевывает в чат.
В случае с встроенным СЯ и имея контроллер K допустим на Ruby получим:
1. П видит команду <planes, и должен спросить К о наличии самолетов
2. Находит у себя объект К
3. Вызывает метод для команды <planes
4. Производит вычисления и определяет наличие самолетов на данном поле.
5. Находит объект Л
6. Вызывает метод объекта Л и получает отфильтрованный список
7. К возвращает список
8. П форматирует, переводит в локаль пользователя и выплевывает в чат.
При этом создание протокола для передачи это отдельная задача, гораздо более сложная и ошибкоемкая чем парсинг лога...
...И от полученных знаний скончался на месте
Это я понял, и именно так себе и представляю.
Но проблема как видим не в сложности технической реализации, а в том, что пришлось бы писать больше кода - классы, функции, методы, т.е. в большей трудоемкости. И лишь для того,чтоб сделать возможным обмен данными между какими-то модулями, а нафиг это нужно "когда я возьму и напишу без геморроя все в одной куче". И это понятно.
Но вы упускаете важный момент, который с вашей колокольни вам кажется незначительным и ненужным. У вас получается достаточно узконаправленный и зажатый в свои рамки блок. И менять или переделывать его для кого-то никто из "отцов" не будет. Да просто лениво делать, особенно то, с чем не согласен. Пример - наш разговор. Не раз сказано "каждый пишет на том, на чем лучше всего умеет писать". Готов ли каждый в одиночку написать комплект софта на своем языке и выдать его как законченный продукт? Теоретически - конечно, но практически - вряд ли. Найдется сотня причин, которые помешают это сделать.
Найдется 2-5 человек которые напишут софт на одном языке - чудесно! А кто против? Главное при этом, чтоб еще 30 человек смогли его использовать в своих целях, иначе говоря, чтоб он полностью отвечал их запросам. Шансы? Минимальные.
Пример. Мне необходимо чтоб SC выдал в чат комманду "Равняйсь, Смирна!" Возможно ? Нет. Он закрыт.
Мне надо чтоб JayDaemon это сделал? Нет. Для этого нужно выучить JAVA, разобраться с исходниками и вставить несколько строк кода. Реально, да.. но бррр, а когдаж карты рисовать? А потом вдруг на С# появится софт, который мне понравится больше, будет интереснее. Да фигня! Теперь учим С#, разбираемся с исходниками и вставляем-меняем.
Нда. Делов то.
Но меня интересует другое:
Есть техническая возможность создать софт, для которого я могу написать несколько строк на xml, например, и этот софт его проглотит и выдаст результат? Или я заполню некоторый шаблон, и на основе его сформируется скрипт или еще какая фигня, которая включится в работу не заставляя изучать новый язык программирования?
Я понимаю, что вам это не надо. Это надо НАМ, не программистам, но режисерам, картостроителям, сценаристам...
А зачем это вам? Незачем. Но может найдется один или несколько програмистов, которым будет интересно решить такую задачу. Именно поэтому я и вынес это на обсуждение, надеясь на удачу. На самом деле это гораздо интереснее и круче, чем свой маленький самодостаточный проект - работает, ну и ладно.
Крайний раз редактировалось boRada; 31.10.2006 в 07:14.
Ваши права
Ответить с цитированием