Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

Вид для печати

Показывать 40 сообщений этой темы на одной странице

27.09.2015, 21:03
Andrew771

Цитата:

Сообщение от krt17

А че писать то, код это вообще не проблема

Вот что по этому поводу пишет Вяч.Медноногов в своей эпопее про Черного Ворона:

Цитата:

Большой прикол в том, что наиболее трудные места пишутся сначала на Cи на РС, а потом переносятся в ассемблер (ручками, конечно). Получается быстрее и надёжнее. В следующий раз думаю целиком сначала на ИБМ состряпать, а только потом - перенести на ZX

Жаль, тогда еще не было кросс-компиляторов ЯВУ для Спектрума. А сегодня уже есть!
27.09.2015, 23:18
jerri

Цитата:

Сообщение от Oleg N. Cher

jerri знает секрет как ускорить процесс реверс-инжиниринга?

шта? Jerri знает про реверс инжинеринг очень много.
чтобы не быть голословным он даже поделится с тобой ссылкой
вот те раз
вот те два
вот те три

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

Цитата:

Хотя и не настолько хорошо (взять хотя бы баги моего бэк-энда - SDCC, которые приходилось править, тратя на это много времени; тоже, кстати, потеря, не связанная с Обероном, не находишь, jerri?)

ты правда считаешь что для написания этой игры у меня было всё?
я переписал столько разного интересного инструментария
например вот или вот

как то так
27.09.2015, 23:22
Oleg N. Cher

Господа, быть может, мой подход к портированию игр вовсе и не оптимален, но когда это фанбои слушали голос разума? - они всегда действовали по велению души. :) Спектрум - фанская платформа.

s_kosorev, так называемые "косяки" Си - это результат общения не только с Паскалем, но с Си в первую очередь, причём общения очень плотного и тесного, сидения в отладчике, переноса кода между платформами и т.п. Как переносимый ассемблер он вполне хорош и по сей день, хотя мог бы быть и получше. Но если роль (удельный вес) в софте ассемблера с течением лет уменьшался, то сегодня людям всё в меньшей степени нужен и переносимый ассемблер. Щас вот набегут спорить, ну ладно, пусть это будет моё субъективное мнение. Языки Java, C# прикрепили к платформе и назвали это кроссплатформенностью. PHP, Perl прикрепили к интерпретатору и назвали так же. Ну пусть. Хотя мне всё равно не нравится. Людям подавай быструю разработку софта. Так что я не стал бы идеализировать язык, который никак не возбраняет накосячить в самом что ни есть прикладном куске кода. На нём будто по минам ходишь каждый свой миг, притом то же самое можно сказать и о Паскале в редакции Дельфи/FPC.

Про Оберон скажу так: он в силу концепта более безопасен. Нету ручного освобождения памяти. Нет возможности из прикладного кода залезть не в свою память. Вообще нельзя. Физически. Получается managed код, притом без всяких виртуальных платформ. Это всё притом на синтаксисе Паскаля базируется. Ессно эти все возможности не про честь ZX, но тут уже что поделать. Мне нравится, господа, когда об Обероне рассуждают как о взрослом языке, который может посягнуть на место не только C++, но и C#, и всё это заслуженно. И оберонщики понимают проблемы Оберона. Посмотрите выступление Рифата на Оберон-дне 2015 (это автор компилятора Exaprog Oberon-07) - он высказал очень здравые вещи и про IDE, и про необходимость пошагового отладчика. Всё это нужно, просто делать некому. Вот так вот. s_kosorev, обязательно посмотрите, пожалуйста. Я не против навороченного IDE. Кстати, можно было бы собрать его на основе плагинов Саши Ильина. Просто мне не надо, я обхожусь БлэкБоксом. А делать впрок вдруг кому-то понадобится - это большая роскошь даже для богатых фирм.

Ещё моментик. Даже если выкинуть Оберон - ZXDev остаётся самой крупной подборкой ZX-библиотек, адаптированных для использования из SDCC. И в этом смысле проекту могли бы помочь любители Си, а вовсе не Оберона, однако почему-то они этого не делают. Кроме Sergey, который предложил библиотеку для работы с TR-DOS, и SfS - библиотеку для вывода спрайтов libspr, которые я адаптировал для ZXDev. Респект!
28.09.2015, 10:35
s_kosorev

Цитата:

Сообщение от Oleg N. Cher

Языки Java, C# прикрепили к платформе и назвали это кроссплатформенностью.

На самом деле в битве кросплатформенных инструментов победил js.

Цитата:

Сообщение от Oleg N. Cher

Нету ручного освобождения памяти. Нет возможности из прикладного кода залезть не в свою память. Вообще нельзя. Физически.

Во первых можно, во вторых сейчас таких языков много, очень много, в третьих, блокирование прямого обращения к памяти не увеличивает надежность, есть еще много разных средств/методик/технологий, повышающих надежность ПО.
У от nasa кстати java на слуху и на марс и на луну и просто полетать. А так читал где то, что nasa если не связано с полетами то использует во всю Python

Цитата:

Сообщение от Oleg N. Cher

Получается managed код, притом без всяких виртуальных платформ.

C#, java можно компилировать в нативный код при помощи утилит, MS уже из коробки для C# сделала нативную компиляцию, пока для UniversalApp но обещают для всего.

Цитата:

Сообщение от Oleg N. Cher

Оберон - ZXDev остаётся самой крупной подборкой ZX-библиотек, адаптированных для использования из SDCC.

если не ошибаюсь, на данный момент самый большой сборник библиотек это z88dk
28.09.2015, 11:14
Vitamin

Побуду адвокатом дьявола.

Цитата:

Сообщение от s_kosorev

Развитый RTTI: C# да, delphi да, с++ нет

"Развитый" - это что именно? Ибо RTTI какбэ в C++ имеется.

Цитата:

Сообщение от s_kosorev

-строки, динамические динамические массивы на уровне языка: C# да, delphi да, с++ нет

Что значит "на уровне языка"? Для с++ есть std::string. Если считать, что это не в языке, а в стандартной (ключевое слово, если что) библиотеке, то для шарпа/явы строки тоже являются производными типами.

Цитата:

Сообщение от s_kosorev

-наличие управления автоматического управления памятью: C# да, delphi местами, c++ нет

Если предположить, что "автоматическим управлением памяти" называется сборщик мусора, то где его места у delphi?

Цитата:

Сообщение от s_kosorev

в с++ вообще строк нет

Да ну?

Цитата:

Сообщение от s_kosorev

В с++ шаблоны compile time, т.е. хитросделаные макросы, в C# параметрический полиморфизм и ноги растут не от с++ а от какого то функционального языка, от с++ взяли синтаксис, в delphi generics есть, в с++ если в целом то нет.

А щто, у нас определение параметрического полиморфизма уже пополнилось требованием быть сугубо runtime?
28.09.2015, 11:33
msm

Олег, выскажу свое ИМХО по поводу Оберона.

Да, с некоторыми доводами я согласен. Но ИМХО главная проблема паскальподобных языков не в плохих IDE и не в плохих отладчиках. Самая большая проблема, которую я вижу - необходимость объявлять переменные и константы в отдельном блоке, а не максимально близко к месту использования. Чем это чревато? А чревато *****кодом, который идет сплошняком от тех, кто долго посидел на паскалеподобных языках.

row[i].col[j].getPerson().getName();
row[i].col[j].getPerson().getLastName();
row[i].col[j].getPerson().getMiddleName();
row[i].col[j].getPerson().getPosition();

И тому подобный копипаст идет сплошняком на паскалеподобных проектах. И самое нехорошее, что человека, который вот так привык писать - потом хрен переучишь, он такое считает нормальным. Пока это не исправят, Оберон ИМХО лучше не рассматривать вообще. Хотя я видел проект что то вроде Оберон под .NET - там в принципе все есть, вполне хороший язык. Вот только это .Net с другим синтаксисом и ничего больше.
28.09.2015, 12:22
Bedazzle

Цитата:

Сообщение от msm

row[i].col[j].getPerson().getName();
row[i].col[j].getPerson().getLastName();
row[i].col[j].getPerson().getMiddleName();
row[i].col[j].getPerson().getPosition();

Это от незнания конструкции with.
28.09.2015, 13:08
msm

with здесь помогает, но не сильно. Во первых уровень вложенности появляется на пустом месте. А этих псевдопеременных может запросто быть штук 5 - 5 уровней вложенности на ровном месте? Или неоднократная копипаста with в пределах метода?

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

Короче, это искусственные сложности на ровном месте. Тут собственно вполне промышленные языки вроде C++, Java, C# зачастую критикуют за слишком громоздкий синтаксис.
28.09.2015, 14:17
s_kosorev

Цитата:

Сообщение от Vitamin

"Развитый" - это что именно? Ибо RTTI какбэ в C++ имеется.

хотя бы как в Qt

Цитата:

Сообщение от Vitamin

Что значит "на уровне языка"? Для с++ есть std::string.

Встроенный в язык тип, var s:string; public string s;

Цитата:

Сообщение от Vitamin

Если предположить, что "автоматическим управлением памяти" называется сборщик мусора, то где его места у delphi?

не сборщик, подсчет ссылок на объекты и начало процесса уничнотежения объекта когда счетчик в 0 перешел

Цитата:

Сообщение от Vitamin

Да ну?

в языке нет, есть строковые константы

Цитата:

Сообщение от Vitamin

А щто, у нас определение параметрического полиморфизма уже пополнилось требованием быть сугубо runtime?

естественно
28.09.2015, 15:11
Vitamin

Цитата:

Сообщение от s_kosorev

хотя бы как в Qt

Это будет нарушением одного из освновополагающих принципов С/С++ - ты не платишь за то, что не используешь.

Цитата:

Сообщение от s_kosorev

Встроенный в язык тип, var s:string; public string s;

А разве в C#/Java он встроенный?

Цитата:

Сообщение от s_kosorev

не сборщик, подсчет ссылок на объекты и начало процесса уничнотежения объекта когда счетчик в 0 перешел

И где такое в делфях?
В плюсах - читать про std::shared_ptr.

Цитата:

Сообщение от s_kosorev

естественно

И где это определение? Ссылочку, пожалста.

Показывать 40 сообщений этой темы на одной странице