Open Source эмуль...

[rg_software]

Ну и правильно глючит - если чел идиот, то так ему и надо. Возможно, ты с вершины ООП даже и не в курсе, что флоатные числа на предмет больше-меньше можно СРАВНИВАТЬ целочисленными сравнениями?... слабо так на жабе сделать?

Ох... Вешать ярлыки -- каждый горазд. Особенно, когда сам не сталкивался с такими вещами. Я могу лишь посоветовать обратиться к литературе, в которой описаны классические ошибки, совершённые программистами мирового класса, и влетевшие в копеечку. Пример с float'ом -- лишь один из них. Другой известный пример -- компиляция фортраном инструкции DO как идентификатора из-за того, что человек случайно поставил точку вместо запятой. Из-за этого при взлёте взорвалась ракета; потеряны были миллионы долларов. Из-за этого, во многом, был разработан язык Ada, в котором все такие штуки сведены к минимуму.

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

Поправка - не 'меняются', а их 'меняют'. Зачем - надеюсь, не надо объяснять?

Зачем обиняками выражаться? Не знаю, зачем и не знаю, кто. Все парадигмы, которые сейчас есть, известны ещё с пятидесятых-шестидесятых.

Парадигмы никто не меняет, это процесс объективный. На майкрософт кивать не надо. ООП появилось в Simula 67, но лишь в 90х годах его стали реально юзать. Парадигма была уже давным-давно.

Вообще я сторонник бизнес-подхода. Если некто пишет программу за неделю на С++ с OOП и STL или даже на Visual Basic, а другой на С за месяц, первый куда выгоднее...

[Advertiser]

[lvd]

Ох... Вешать ярлыки -- каждый горазд. Особенно, когда сам не сталкивался с такими вещами. Я могу лишь посоветовать обратиться к литературе, в которой описаны классические ошибки, совершённые программистами мирового класса, и влетевшие в копеечку. Пример с float'ом -- лишь один из них. Другой известный пример -- компиляция фортраном инструкции DO как идентификатора из-за того, что человек случайно поставил точку вместо запятой. Из-за этого при взлёте взорвалась ракета; потеряны были миллионы долларов. Из-за этого, во многом, был разработан язык Ada, в котором все такие штуки сведены к минимуму.

Ни один язык и метод не гарантирует от ошибок, в том числе и ада, и ооп... дальше что? Не будет одних ошибок, будут другие - и не факт, что их будет легче найти.

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

Покуда целые знаковые числа представляются дополненением до 2, а флоаты - по стандарту ИЕЕЕ - можно. Если конечно считать, что это не так - то тогда и биты нельзя анализировать на сях и сдвиги делать (а то вдруг попадётся какая-нить архитектура с троичной, а не двоичной основой?).

Парадигмы никто не меняет, это процесс объективный. На майкрософт кивать не надо. ООП появилось в Simula 67, но лишь в 90х годах его стали реально юзать. Парадигма была уже давным-давно.

Парадигмы тут причём? Я говорю о том, что некрософт всех пересаживает на до-диез и дотНЕТУ, например - ты не согласен?

Вообще я сторонник бизнес-подхода. Если некто пишет программу за неделю на С++ с OOП и STL или даже на Visual Basic, а другой на С за месяц, первый куда выгоднее...

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

Вот только что пока в рамках 'эхотага' такого нету - и слава погу.

[rg_software]

Ни один язык и метод не гарантирует от ошибок, в том числе и ада, и ооп... дальше что? Не будет одних ошибок, будут другие - и не факт, что их будет легче найти.

Безусловно. Но тех не будет -- и слава богу! Я читал недавно одну книгу по программированию, написанную в 79 году. Так там такие "советы" даются! Это диву даёшься! Мы от них так далеко ушли (в лучшую сторону), что я благодарен судьбе за то, что мне не приходится заниматься той мурой, что занимались предки... 90% всех ошибок, которым уделялось там внимание, решаются благодаря умной организации языка программирования... И нынешние ошибки -- лишь следствие того, что мы хотим большего. В те времена Pacman был сложным коммерческим проектом; сейчас я его за один вечер напишу.

Покуда целые знаковые числа представляются дополненением до 2, а флоаты - по стандарту ИЕЕЕ - можно. Если конечно считать, что это не так - то тогда и биты нельзя анализировать на сях и сдвиги делать (а то вдруг попадётся какая-нить архитектура с троичной, а не двоичной основой?).

Ну хорошо; а почему ты думаешь, что сравнение float'ов в С++ происходит не так? Кто мешает оптимизатору воспользоваться этим фактом?

Кстати, года четыре назад у меня был один удивительный результат. В одной программе я попытался заменить вычисления синусов и косинусов табличными значениями (стандартная оптимизация). Выгоды почти никакой не получилось -- математический сопроцессор и так замечательно считал...

Парадигмы тут причём? Я говорю о том, что некрософт всех пересаживает на до-диез и дотНЕТУ, например - ты не согласен?

Нуу... и да, и нет. Я помню, какой был вопль году так в 96-98, что все завтра будут только на Джаве сидеть. Сидят?
Дот-нет, кстати, вещь хорошая. А если Майкрософт реализует аппаратную поддержку (о чём они мечтают), то и по скорости будет не хуже ассемблера. Да и, насколько понимаю, обычные (не дот-нет) приложения никто не отменяет. И уверен, что не отменит.

Угу, побыстрее наклепать, побыстрее продать, побыстрее забыть, побыстрее забить - в общем, в добрый путь.
Вот только что пока в рамках 'эхотага' такого нету - и слава погу.

Да ради бога. Когда ты пишешь для своего удовольствия -- можно юзать ZX Spectrum Basic, чтобы слеза ностальгии прошибала. Может, я тоже чего подобное юзаю, пока никто не видит

Но я отказываюсь понимать, когда человек предпочитает копать лопатой, а не экскаватором. И единственная тому причина -- ему влом прочесть мануал по пользованию экскаватором...

[elf/2]

Парадигмы тут причём? Я говорю о том, что некрософт всех пересаживает на до-диез и дотНЕТУ, например - ты не согласен?

а почему это плохо? особенно учитывая наличие Mono и dotGNU.
на мой взгляд у MS получилось очень не плохо в плане удобства разработки/скорости работы/etc

[elf/2]

Дот-нет, кстати, вещь хорошая. А если Майкрософт реализует аппаратную поддержку (о чём они мечтают), то и по скорости будет не хуже ассемблера. Да и, насколько понимаю, обычные (не дот-нет) приложения никто не отменяет. И уверен, что не отменит.

о как! я что-то пропустил? MS начинает играть на рынке hardware?

[rg_software]

о как! я что-то пропустил? MS начинает играть на рынке hardware?

Необязательно играть самому, достаточно заключить хороший альянс

Пару лет назад я был на одной презентации, где представители M$ и Intel взахлёб признавались в любви друг другу
Windows XP, дескать, специально оптимизирована под Pentium IV, а Pentium 4 разрабатывался чуть ли не исключительно для Windows XP...

Посмотрим, что из этого получится...

[Adramelek]

Пару лет назад я был на одной презентации, где представители M$ и Intel взахлёб признавались в любви друг другу
Windows XP, дескать, специально оптимизирована под Pentium IV, а Pentium 4 разрабатывался чуть ли не исключительно для Windows XP...

Посмотрим, что из этого получится...

У Microsoft'a, помнится, был уже альянс с IBM'ом...

[Error404]

Посоветуйте, пожалуйста, хороший современный сабж для экспериментов (под Windows)!

Из того, что пробовал, пока более-менее удовлетворил DelphiSpec, но там свои проблемы...

А так -- большинство проектов недоработаны, либо кучи доп. библиотек требуют (пока скомпилишь, проклянёшь всё на свете), либо написаны настолько криво, что к коде чёрт ногу сломит...

А вот кстати: кто-нибудь пользовался этим DelphiSpec ? Чего-то там в AY8312 недоэмулировано: эмулятор постоянно хрюкает "сам с собой" даже в Idle. Никто не сталкивался? Это как-то фиксится (исходники же есть)?

[fk0]

[QUOTE=rg_software]"Fuse - the Free Unix Spectrum Emulator"?
Во-первых, Уних, а это значит, что для портирования под винду повозиться всё-таки придётся...
Во-вторых, при всём уважении, эти ребята юзают чистый С, что в наше время мне кажется, мягко говоря, странным... У меня нет предубеждений
[/quite]

Ну да. Современные программы должны писаться непременно на Java.
А лучше на C#. А то не заработают.

[fk0]

Чистый С -- язык морально устаревший. Созданный в конце семидесятых, он прекрасно отражал воззрения на программирование того времени. Сейчас в свете развития ООП и прочего, становится совершенно ясно, чего мне не хватает в С:

Мне кажется, аффтару самому ещё немного устареть, насмотреться на все ужасы ООПщины и перестать бредить -- и будет полный порядок.

1) прилично организованной модульности и средств абстракции данных (классов то бишь)

А у лыж нет колёс. Поэтому лыжи -- *****. То ли дело самокаты.