Просмотр полной версии : Немного крамольная статья о жизни Спектрума в новом тысячелетии
Это для затравки, тезисно,подробная статья будет на страничке НФСП.
Чтобы возродить истиный и широкий интерес к платформе, нужно предложить широким слоям "самодельщиков" что-то современное.
Было бы интересно создать недорогой, легко повторяемый сетевой компьютер на основе ядра z80, или его расширений ( ez80, Rabbit и т.п.). Самым массовым и распространенным языком программирования на сегодня является Java! Это можно оспаривать, но все-таки это так :smile: Протоколы на нижнем уровне могут быть как упрощенными, так и стандартными. Первое так же интересно для закрытых корпоративных сетей. И наконец, сбывается давнишняя мечта спектрумистов, через год-два в секонд попадут жки-шные цветные дисплеи подходящего разрешения с мобильных телефонов( правда отчего тогда не использовать и остальное?), ну этим пусть озадачаться эмуляторщики. Эмули нужны не только для настольных приложений, но и для мобильных. Ассемблер и С должны быть забыты!
Актуальны "повышающие" конверторы кода ассемблер->c->c++->java. В этом случае платформа становится мобильной и актуальной. Интересный и открытый вопрос usb-host, но вроде есть подвижки в изменении стандарта ( в связи с цифровыми фотокамерами) и может быть появиться, что-нибудь более простое.
Крамола же заключается в коренном изменении архитектуры платформы. Останется только экран небольшой информационной емкости, что позволит оставить "архитектурные рамки" для проектов с малым бюджетом. Вопрос о wifi и irda тоже актуален. Мобильники приучили юзеров к мысли о том, что "шнурки" - это архаичные атрибуты прошлого тысячелетия.
Это для затравки, тезисно,подробная статья будет на страничке НФСП.
Чтобы возродить истиный и широкий интерес к платформе, нужно предложить широким слоям "самодельщиков" что-то современное.
Было бы интересно создать недорогой, легко повторяемый сетевой компьютер на основе ядра z80, или его расширений ( ez80, Rabbit и т.п.). Самым массовым и распространенным языком программирования на сегодня является Java! Это можно оспаривать, но все-таки это так :smile: Протоколы на нижнем уровне могут быть как упрощенными, так и стандартными. Первое так же интересно для закрытых корпоративных сетей. И наконец, сбывается давнишняя мечта спектрумистов, через год-два в секонд попадут жки-шные цветные дисплеи подходящего разрешения с мобильных телефонов( правда отчего тогда не использовать и остальное?), ну этим пусть озадачаться эмуляторщики. Эмули нужны не только для настольных приложений, но и для мобильных. Ассемблер и С должны быть забыты!
Актуальны "повышающие" конверторы кода ассемблер->c->c++->java. В этом случае платформа становится мобильной и актуальной. Интересный и открытый вопрос usb-host, но вроде есть подвижки в изменении стандарта ( в связи с цифровыми фотокамерами) и может быть появиться, что-нибудь более простое.
Крамола же заключается в коренном изменении архитектуры платформы. Останется только экран небольшой информационной емкости, что позволит оставить "архитектурные рамки" для проектов с малым бюджетом. Вопрос о wifi и irda тоже актуален. Мобильники приучили юзеров к мысли о том, что "шнурки" - это архаичные атрибуты прошлого тысячелетия.
Безсмысленно делать Java на не 32-битном ядре, куда проще и главное дешевлее использовать АРМ9-процессор (EP9312 от Cirrus например) который включает в себя все (по сути является систем он чип). И куча ПО к нему имеется. СОбственно все ембеддеры давно уже перешли на такие фичи, самое интересное что и джава машины существуют уже готовые для таких систем.
Бред. По железу всё уже ясно.
Либо клон, либо эмулятор (хоть на чем).
Ну может и какие промежуточные варианты.
Ассемблер и С должны быть забыты!
А вместе с ними квалифицированный слой кодеров...
Ява - зло. Хоть как плюйтесь, но ява - зло.
А вместе с ними квалифицированный слой кодеров...
Ява - зло. Хоть как плюйтесь, но ява - зло.точняк! любого фаната низкоуровневого программирования от жабы с души воротит, а жаберам этого и подавно не надо.
точняк! любого фаната низкоуровневого программирования от жабы с души воротит, а жаберам этого и подавно не надо.
Фанатам низкоуровнего программирования предложение написать банальный магазин и запустить его на любом кластере. Напишите или нет - дело десятое, интересуют два вопроса: за сколько напишите и как легко запустите на произвольной платформе.
Фанатам низкоуровнего программирования предложение написать банальный магазин и запустить его на любом кластере. Напишите или нет - дело десятое, интересуют два вопроса: за сколько напишите и как легко запустите на произвольной платформе.
Гы-гы :) Фанатам высокоуровнего програмирования предлагается написать ПО для банковского терминала у которого 256кб оперативной памяти и процессор ну например МС68302.
Просто есть определенные задачи и есть языки для их решения.
Это для затравки, тезисно,подробная статья будет на страничке НФСП.
О да! Национальный Фонд СПектрума.
Афтар жжошь, пей йад.
Было бы интересно создать недорогой, легко повторяемый сетевой компьютер на основе ядра z80, или его расширений ( ez80, Rabbit и т.п.). Самым массовым и
Скажем прямо -- Z80 -- разработка 1976г. В настоящее время полностью не актуален.
Практически везде, где задача стоит чуть болше, чем дёргать ножками -- 32-бита уже
здесь и сейчас, и дешевле причём (а именно -- ARM-производные MCU).
распространенным языком программирования на сегодня является Java! Это можно оспаривать, но все-таки это так :smile:
И что? Вчера распространённым языком являлся фортран... Где он сегодня?
А как же всемогущий Си-два-креста?
Универсальной затычки ко всем бочкам нет. А Java -- это убогонький дельфи с
C-шным синтаксисом (может я конечно что-то не понимаю, но что именно?)
Java никогда не заменить универсальный ассемблер C, равно как и не заменит
динамические языки вроде perl или tcl.
давнишняя мечта спектрумистов, через год-два в секонд попадут жки-шные цветные дисплеи подходящего разрешения с мобильных телефонов( правда отчего тогда не использовать и остальное?),
Точно. Бери wireless toolkit и пиши. При чём тут спектрум?
Ассемблер и С должны быть забыты!
Не в этой жизни. В ОС на моём десктопе C -- больше половины приложений.
Остальное -- по большей части C++, perl и python, реже scheme (lisp), tcl и ruby.
У меня есть РОВНО ОДНО жабовское приложение. Пол-системы встаёт в позу когда
оно запускается (просто добавь памяти...)
Актуальны "повышающие" конверторы кода ассемблер->c->c++->java. В этом случае платформа становится мобильной и актуальной. Интересный и открытый вопрос
Мобильность на уровне бинарников -- она зачастую НАФИГ НЕ НУЖНА. Даже в
виде жаба-апплетов и браузер или мидлетов в мобильник. Классический пример --
javascript и tclовский апплет -- никаких бинарников, всё мобильно и на уровне исходного кода. Для защиты авторского права (т.е. если код просто стыдно показатЬ) -- есть обфускаторы.
Мобильность бинарников в рамках универсальной ОС -- она тем более не нужна.
Т.е. нужна для закрытых коммерческих приложений в случае, когда поддерживать
его на множестве платформ оказывается неинтересно (типичный пример -- эмулятор линуха в FreeBSD). В остальных случаях уровень совместимости -- как раз C-шный код. Ниже уже некуда, а выше -- сплошь серьёзные ограничения как на уровне интерфейсов ОС, так и в плане ресурсоёмкости приложений.
Гы-гы :) Фанатам высокоуровнего програмирования предлагается написать ПО для банковского терминала у которого 256кб оперативной памяти и процессор ну например МС68302.
Легко. Как только яву придумают для МС68302. А если ты такой умный, почему не собираешь АТМ на транзисторах, без использования каких-либо имс? Или вобще на диодах?
Просто есть определенные задачи и есть языки для их решения.
С этого надо начинать дискуссию. Я могу развести здесь диссертацию на тему почему ООП лучше ПП, но за меня это уже давно сделали :)
Фанатам низкоуровнего программирования предложение написать банальный магазин и запустить его на любом кластере.
Есть один ньюанс: когда проект разрастается достаточно -- АБСОЛЮТНО ПОФИГ НА ЧЁМ ОНО НАПИСАНО. Может слегка утрирую, но мысль примерно такая.
Напишите или нет - дело десятое, интересуют два вопроса: за сколько напишите и как легко запустите на произвольной платформе.
Вопрос: что мне даст java? Я понимаю, что реализация того же самого на C заставляет решать массу уже решённых вопросов. Но java -- это не единственное верное средство здесь. Эти магазины на php и perl пишут пачками, наверное больше чем на java (я так, просто на freshmeat посмотрел, особо не вникал -- может и не прав).
Есть один ньюанс: когда проект разрастается достаточно -- АБСОЛЮТНО ПОФИГ НА ЧЁМ ОНО НАПИСАНО. Может слегка утрирую, но мысль примерно такая.
Абсолютно верно. Здесь только два нюанса, причём последний прямо зависит от первого. Так вот первый - это деньги. Самоё дешёвое написать на php и прочем сброде, можно нанять кучу второкурсников и написать за смешные деньги, благо php простой как три копейки. Второй нюанс - если нужна массштабируемость, то php вкупе с С и С++ (в виде cgi) сразу курят в сторонке, а она понадобится сразу же после первого месяца жизни магазина, когда суперлинукс на четвёртом пне ежесуточно будет вставать на колени от тысячи хитов и судорог левой mysql (единственная база данных, от которой у меня устойчивые рвотные позывы, даже на MS Access такой реакции нет).
Вопрос: что мне даст java? Я понимаю, что реализация того же самого на C заставляет решать массу уже решённых вопросов. Но java -- это не единственное верное средство здесь. Эти магазины на php и perl пишут пачками, наверное больше чем на java (я так, просто на freshmeat посмотрел, особо не вникал -- может и не прав).
Ява тебе даст:
а) быструю разработку - меньшая стоимость проекта
б) удобную администрацию проекта (апдейты, апгрейды, та же масштабируемость и пр. , а это всё опять же деньги)
в) настоящую кроссплатформенность, которой до сих пор не может похвастаться ни С, ни С++.
Можно составить списки для С и С++, php и прочем.
Но ни одному нормальному человеку не придёт в голову писать десктоповые апликации или драйвера на яве. Ибо кесарю кесарево...
Легко. Как только яву придумают для МС68302. А если ты такой умный, почему не собираешь АТМ на транзисторах, без использования каких-либо имс? Или вобще на диодах?
Ну вообщето можно сказать что я собираю на транзисторах и диодах, токо упакованных в большие блоки... Кстати к языкам ВУ это так же относится. Таже жава машина - написана далеко не на жаве.
СПасибо кстати за комплемент :).
С этого надо начинать дискуссию. Я могу развести здесь диссертацию на тему почему ООП лучше ПП, но за меня это уже давно сделали :)
Токо идиот моджет утверждать что ООП лучше, ибо он ЛУЧШЕ ТОЛЬКО ДЛЯ ОПРЕДЕЛЕННОГО КЛАСА ЗАДАЧ.
Ннапример какой нить ембедед-контроллер лифта или клавиатуры писать на ООП просто безсмыслено. Ну или ближе к теме ты видел где нить 4К-intro написанное на ООП? :biggrin:
"собираю на транзисторах и диодах"
А собственно в чем проблема? Буржуи вовсю процессора
на мелкой логике собирают ... И не парятся с языками ...
Микрокод рулит :)
У некоторых в коллекции и транзисторная ивм найдётся :)
Это вопрос желания - кому с чем охота повозиться ...
У меня например, с детства мечта - собрать ОЗУ на проволоке
(звукорые волны в металле) :)
Таже жава машина - написана далеко не на жаве.
СПасибо кстати за комплемент :).
Ага, есть например железные имплементации JVM и что?
Токо идиот моджет утверждать что ООП лучше, ибо он ЛУЧШЕ ТОЛЬКО ДЛЯ ОПРЕДЕЛЕННОГО КЛАСА ЗАДАЧ.
Померяемся письками? ООП подходит для большинства задач. Ты будешь с этим спорить?
Ннапример какой нить ембедед-контроллер лифта или клавиатуры писать на ООП просто безсмыслено.
Абсолютно верно. Однако полемика началась не в контексте каких-то мк. Не путай тёплое с мягким.
Ну или ближе к теме ты видел где нить 4К-intro написанное на ООП? :biggrin:
Где ты видел интро, которое приносило какую-нибудь пользу/выгоду? И я где-то утверждал, что только ява тру?
Было так:
"предложить широким слоям "самодельщиков" что-то современное.
Было бы интересно создать недорогой, легко повторяемый сетевой компьютер на основе ядра z80, или его расширений "
Но это бред. Для современного - надо использовать современные решения,
а не ядра Z80 ... А для "ретро" - другие требования.
Это и дауну понятно.
итак, какие VM (virtual machine) на сегодняшний день имеют место быть, имея в виду не только SUN, но и кого-угодно ваяющего по их спецификации. С полтыка и по ссылкам с этого форума я наткнулся на полдюжины проектов по разработке и портированию JVM на архитектуры вплоть до быстрых 100MHz 8-битных RISC процессоров ( у Rabbit4000 кстати говоря 60MHz расширенный (с ethernet-прибамбасами)проц, поддерживающий операции с 16 и 32-битными данными, адресуемая страничная память до 16 Мбайт.
ARM-9 и ARM-7 тоже неплохо, но чем хуже интель или моторола в мобильниках с этой точки зрения(ведь не z80 ядро все равно потребует эмуляции для запуска "классического" софта). Относительно JAVA прозвучали разумные голоса о масштабируемости и портируемости(ведь собственно на портируемость и делался упор при разработки этой технологии). С++ для ZX Spectrum все-равно до сих пор так и не создан!
С же есть и для Rabbit4000. Если у кого есть удачно заточенный инструмент для ZX Spectrum на основе IAR, GNU, или прочего поделитесь со всеми! Не нужно никому объяснять, что инструментария(бесплатног� �) для жабы, да и самих jdk всюду навалом.
Что же касается низкоуровнего кодирования, то для жабки такая возможность тоже имеется.
Раббит сильно дороже того же АРМа поэтому они у нас не очень приживаются, да и достать их в России сложно.
Джава язык прикольный, но крайне ресурсоемкий. Я честно говоря для персоналок видел только одно ядро Java которое полностью являлось ОС (от Novell), остальное это виртуальные машины под ОС.
Когда увидим суперкомпьютер Rabbit4000ZX, тогда и поговорим ...
А так - эта Jav-ный ананизм :)
Что же касается низкоуровнего кодирования, то для жабки такая возможность тоже имеется.
Какой ценой знаешь?
Да и вообще это от лукавого. Именно на Спектруме не хватает С.
Джава язык прикольный, но крайне ресурсоемкий.
Заблуждение, которым всегда руководствуются, опуская яву :) Ничего личного.
Померяемся письками? ООП подходит для большинства задач. Ты будешь с этим спорить?
Давай сначала определимся в понятии "большинства задач", например ембеддед контроллеры распространены гораздо больше чем персоналки и сервера - т.е. задачи решаемые ими это большинство получается. Меряться с тобой не интересно, ибо с логикой проблемы - у тебя религиозный подход к теме. Главное понять что ООП это не панацея, а только средство решения.
Похожую тему как то Нэмо раскрывал - он попросил както чела перерисовать схему, чтобы потом размножить на ризографе. Ну чел естественно сказал типа щаз мы в ПЦ все загоним и быстро нарисуем, в итоге через неделю работа еще не была готова. Потом Нэмо пошел к другому челу и тот ему нарисовал вручную на бумаге за полтора часа.
Я к тому, что ООП это хорошо, но все решать через ООП - это плохо.
Заблуждение, которым всегда руководствуются, опуская яву :) Ничего личного.
Опять религия... Берем обычную ПЦ, задача - ну просто доступ к базе с наружи через IP, ты пишешь серверную часть на Джава, я пишу на С++ - мое решение будет быстрее в разы.
Какой ценой знаешь?
Я знаю, писал нативные расширения для шифровальных алгоритмов не реализованных в джаве, так как ключи и сертификаты лежали на внешних носителях. Кстати ничего сложного - доки хорошо у Sun описаны.
Давай сначала определимся в понятии "большинства задач", например ембеддед контроллеры распространены гораздо больше чем персоналки и сервера - т.е. задачи решаемые ими это большинство получается.
Давай сначал определимся, откуда в дисскуссии вообще мк появились. А то потом снова напишешь, что в МО медведей вообще нет.
Меряться с тобой не интересно, ибо с логикой проблемы - у тебя религиозный подход к теме. Главное понять что ООП это не панацея, а только средство решения.
Да нет, с логикой у меня как раз всё нормально. Я предложил мерятся, потому что думаю, что мой опыт программиста поболее твоего будет (на различных языках и различного рода софт). Вот теперь это личное ;) А то что ООП не панацея - никто это не утверждал и за всю дискуссию конкретно я нигде не сказал, что ява - решение всех проблем. Если до сих пор непонятно - ява достаточно мощный язык, а писать софт с использованием ООП намного удобней/дешевле/быстрее и приятнее, чем с ПП. Подавляющее большинство софта - это всякого рода оффисы и прочие веб-сайты. причём каждый непохож на предыдущий, чего не скаешь о мк в лифте. То что я согласен с тем, что каждому языку находится применение ты просмотрел наверное.
ПО сущетсву мне кажеться притягивание "за уши" Z80 к решению проблем для которых он не предназначен - ошибочный путь. На данном этапе он хорош именно для образовательных задач. Т.е. понимание работы, архитектуры компьтера и периферийных устройств, вот где действительно раздолье для применения. Ведь все можно узнать досконально на самом низком уровне - вот основное преимущество такого компьютера.
Ведь беда современных специалистов полное незнание архитектуры и принципов работы. А отсуда принципиальные ошибки в построении систем (в том числе и программных) и незнание как бороться с элементарными техническими проблемами.
Ага, т.е. будем мерятся? Ну давай.
Опять религия...
Это ты снова придумал. Я очень много писал на С++, Дельфи, VBA и ещё кучи всяких языков. И думаю не я один такой :)
Берем обычную ПЦ, задача - ну просто доступ к базе с наружи через IP, ты пишешь серверную часть на Джава, я пишу на С++ - мое решение будет быстрее в разы.
Докажи. Давай замеры сделаем. Задачу можно расширить: база находится на кластере, а в качестве доп. условия - замер времени написания и база Oracle (что бы ты писал через oci и я тоже).
Я знаю, писал нативные расширения для шифровальных алгоритмов не реализованных в джаве, так как ключи и сертификаты лежали на внешних носителях. Кстати ничего сложного - доки хорошо у Sun описаны.
Что есть "нативные расширения" и какие алгоритмы шифрования не реализованы в яве. И на чём писал (ОС, язык). И с коих пор у явы проблемы с внешними носителями?
Давай сначал определимся, откуда в дисскуссии вообще мк появились. А то потом снова напишешь, что в МО медведей вообще нет.
Я их привел, ибо у тебя программирование все упирается в "офисы" ;).
Что есть "нативные расширения" и какие алгоритмы шифрования не реализованы в яве. И на чём писал (ОС, язык). И с коих пор у явы проблемы с внешними носителями?
Батенька читаем спецификацию Java, раз незнаем что такое native.
Ну например внешний носитель SmartCard или Dallas Button или еще черт знает чего. ВЕсь спектр устройств охватить невозможно.
В Джава не реализованы ГОСТовские методы шифрования (представляешь такие бывают :) ).
Докажи. Давай замеры сделаем. Задачу можно расширить: база находится на кластере, а в качестве доп. условия - замер времени написания и база Oracle (что бы ты писал через oci и я тоже).
Т.е. при моей постановке задачи ты уже сдаешся? Тебе нужны дополнительные условия :).
Я их привел, ибо у тебя программирование все упирается в "офисы" ;).
Слив засчитан ;)
Батенька читаем спецификацию Java, раз незнаем что такое native.
Не знаем, потому падаем на колени и умоляем объяснить твоё понимание нативности.
Ну например внешний носитель SmartCard или Dallas Button или еще черт знает чего.
Ты про написание дров для этих носителей или что? При чём тут ява тогда?
ВЕсь спектр устройств охватить невозможно.
В Джава не реализованы ГОСТовские методы шифрования (представляешь такие бывают :) ).
Так причём же нативность в ГОСТОвских методах шифрования?
Т.е. при моей постановке задачи ты уже сдаешся? Тебе нужны дополнительные условия :).
Хорошо, без дополнительных условий. Но раз уж ты поставил задачу, я настиваю на праве выбора базы. Оракл на одной конкретной машине. Принимаешь?
Не знаем, потому падаем на колени и умоляем объяснить твоё понимание нативности.
JavaTM Native Interface (JNI) is a standard programming interface for writing Java native methods and embedding the JavaTM virtual machine* into native applications. The primary goal is binary compatibility of native method libraries across all Java virtual machine implementations on a given platform.
Ты про написание дров для этих носителей или что? При чём тут ява тогда?
Так причём же нативность в ГОСТОвских методах шифрования?
Удивительный ты человек, иногда такие вопросы очевидные задаешь. Ну есть дрова под эти девайсы, но из Джавы ты их не достанешь. Нативность методов ГОСТа в том что ключи используются с внешнихносителей которые не доступны с джава.
Если хо продолжить дискусию - моя аська 44613546. По поводу Оракла, я его нифига не знаю. Обычно с базами работаю через стандартные интерфейсы например ADO.
JavaTM Native Interface (JNI) is a standard programming interface
Ага, т.е. ты действительно JNI имел в виду. А что, Native Interface на русский переводится как нативное расширение?
Удивительный ты человек, иногда такие вопросы очевидные задаешь. Ну есть дрова под эти девайсы, но из Джавы ты их не достанешь.
Не понимаю. Как так может быть? Дрова - это уровень ОС, грубо говоря, никаким боком к JVM отношения не имеет. Если ОС видит устройство вв, его видит и JVM. Под какую ОС писал?
Если хо продолжить дискусию - моя аська 44613546. По поводу Оракла, я его нифига не знаю. Обычно с базами работаю через стандартные интерфейсы например ADO.
Дискуссию продолжать не будем, если ты речь завёл про ADO, то у меня однозначно длинее :), но условия до сих пор принимаю. Кстати, а что будешь делать, если к базе нет ADO драйвера? И зачем, работая через ADO, знать Оракл? Я Оракл просто взял, потому что я думал, что ты из С++ с базой работаешь в обход всяких ODBC, OleDB и прочего, а в нём немного сложно использовать нативный драйвера.
И ещё - не принимай сходу что-то лично, я белый и пушистый :v2_cheer:, не веришь - посмотри на аватар.
Ага, т.е. ты действительно JNI имел в виду. А что, Native Interface на русский переводится как нативное расширение?
Да-да интерфейс нативный нужен для.. правильно изготовления расширений, добавлений и прочего ;).
Не понимаю. Как так может быть? Дрова - это уровень ОС, грубо говоря, никаким боком к JVM отношения не имеет. Если ОС видит устройство вв, его видит и JVM. Под какую ОС писал?
Под вин. Фишка в том что устройство нестандартные и не будут видны как файловая система или еще что либо. Обращение с ними идут токо напрямую через драйвер и специальную библиотеку.
Дискуссию продолжать не будем, если ты речь завёл про ADO, то у меня однозначно длинее :), но условия до сих пор принимаю. Кстати, а что будешь делать, если к базе нет ADO драйвера? И зачем, работая через ADO, знать Оракл? Я Оракл просто взял, потому что я думал, что ты из С++ с базой работаешь в обход всяких ODBC, OleDB и прочего, а в нём немного сложно использовать нативный драйвера.
Если нету драйвера то я посылаю эту базу в сад или использую ее родной интерфейс. Да я не являюсь специалистам по базам, я больше занимался системами шифрования (CryptoAPI) и сетевыми клиентами/серверами (WinSockAPI) и совершенно точно знаю что реализация сетевого интерфейса на Java в порядки медленее С++ (даже замеры делали).
Сейчас моя работа вообще с виндоз-системами не связана.
И ещё - не принимай сходу что-то лично, я белый и пушистый :v2_cheer:, не веришь - посмотри на аватар.
Да я к тебе привык уже, был ближе попили бы одноаваторного с тобой пива.
Под вин. Фишка в том что устройство нестандартные и не будут видны как файловая система или еще что либо. Обращение с ними идут токо напрямую через драйвер и специальную библиотеку.
Понимаю, что оффтопик, но где об этом можно почитать? (SMT наверное знает ;)) Видать я что-то важное в винде пропустил.
Если нету драйвера то я посылаю эту базу в сад или использую ее родной интерфейс.
Ну, это и есть нативные дрова (по краней мере их называют native drivers).
совершенно точно знаю что реализация сетевого интерфейса на Java в порядки медленее С++ (даже замеры делали).
Что значит реализация сетевого интерфейса? Собственный протокол на базе TCP или что? Как раз такие вещи в яве пишутся на ура. Причём в отличии от С думать много не надо :)
Да я к тебе привык уже, был ближе попили бы одноаваторного с тобой пива.
Это да, в МСК надо как-нибудь опять выбраться...
Что значит реализация сетевого интерфейса? Собственный протокол на базе TCP или что? Как раз такие вещи в яве пишутся на ура. Причём в отличии от С думать много не надо :)
Угу некий протокол обмена....
Они пишутся то наура, но уж больно медленно работают :(. На с++ не сложнее пишутся, токо надо много фишек знать - наче багов навалять можно конкретно. ;).
Ждем ждем в мск! Ну или я может как нить выбирусь в дойчландию.
Все давай тему эту закроем.
Обсуждаем что реально сделать на базе нашего любимого спеки.
Vladimir Kladov
04.05.2006, 19:10
примечание: ADO может работать через ODBC. Если у базы нет ODBC-драйвера, то это не база. Продолжайте дискутировать. Только не надо приравнивать Delphi и жабу. Delphi более равен C++, чем жабе.
Только не надо приравнивать Delphi и жабу. Delphi более равен C++, чем жабе.
Наоборот, жаба более равна С++, нежели Дельфи. А если посмотреть на пятую жабу с её генериками, так по-моему вообще все сомнения отпадают :)
Понимаю, что оффтопик, но где об этом можно почитать? (SMT наверное знает) Видать я что-то важное в винде пропустил.
например, влом было писать драйвер файловой системы и всё общение с устройством сделано через DeviceIoControl с самодельным простеньким протоколом (например, некоторые телефоны при usb-подключении видны как диск, а некоторые - нет, только через софт)
универсальный ассемблер C ;-) чей (c)?
задача - ну просто доступ к базе с наружи через IP, ты пишешь серверную часть на Джава, я пишу на С++ - мое решение будет быстрее в разыда не будет никакой разницы, основное время запроса тратится внутри БД. а вот если предложить на жабе написать XVID-декомпрессор, или ещё какой реалтайм фильтр, тут она сольёт по полной (тем более, что современные С умеют SSE)
Круто читать такие треды!
о чем был тред? Сабж собственно:
Это для затравки, тезисно,подробная статья будет на страничке НФСП.
Чтобы возродить истиный и широкий интерес к платформе, нужно предложить широким слоям "самодельщиков" что-то современное.
Было бы интересно создать недорогой, легко повторяемый сетевой компьютер на основе ядра z80, или его расширений ( ez80, Rabbit и т.п.). Самым массовым и распространенным языком программирования на сегодня является Java! Это можно оспаривать, но все-таки это так Протоколы на нижнем уровне могут быть как упрощенными, так и стандартными. Первое так же интересно для закрытых корпоративных сетей. И наконец, сбывается давнишняя мечта спектрумистов, через год-два в секонд попадут жки-шные цветные дисплеи подходящего разрешения с мобильных телефонов( правда отчего тогда не использовать и остальное?), ну этим пусть озадачаться эмуляторщики. Эмули нужны не только для настольных приложений, но и для мобильных. Ассемблер и С должны быть забыты!
Актуальны "повышающие" конверторы кода ассемблер->c->c++->java. В этом случае платформа становится мобильной и актуальной. Интересный и открытый вопрос usb-host, но вроде есть подвижки в изменении стандарта ( в связи с цифровыми фотокамерами) и может быть появиться, что-нибудь более простое.
Крамола же заключается в коренном изменении архитектуры платформы. Останется только экран небольшой информационной емкости, что позволит оставить "архитектурные рамки" для проектов с малым бюджетом. Вопрос о wifi и irda тоже актуален. Мобильники приучили юзеров к мысли о том, что "шнурки" - это архаичные атрибуты прошлого тысячелетия.
А чем кончилось? Измерением длины пиписек Жабы и С++ между Романом и Белым Мишкой с последующей стрелой на распитие пивка. LOL!
А мне вот интересно, зачем автору поста тогда спек? Чем тогда писюк не устраивает?
например, влом было писать драйвер файловой системы и всё общение с устройством сделано через DeviceIoControl с самодельным простеньким протоколом (например, некоторые телефоны при usb-подключении видны как диск, а некоторые - нет, только через софт)
Это грязный хак :)
а вот если предложить на жабе написать XVID-декомпрессор, или ещё какой реалтайм фильтр, тут она сольёт по полной (тем более, что современные С умеют SSE)
Ну есть например JivX. Но не для этого ява придумана. А если уж на принцип идти: пишешь на яве, компиляешь потом в нативный код :)
Alexander Bondarenko (500:3432/3)
08.05.2006, 12:35
*Здравствуй, Alexey!*
Лови мои идеи по поводу сабжа "Hемного крамольная статья о жизни Спектрума в новом тысячелетии", о котором трещала в 04 May 2006 твоя портянка к тов. All.
Ассемблер и С должны быть забыты!
А вместе с ними квалифицированный слой кодеров...
Ява - зло. Хоть как плюйтесь, но ява - зло.
Спёк без асма - ни есть Спёк!
/Вот и всё, Alexey, можешь листать дальше.../
... Достоинства выставляют с целью скрыть недостатки.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot