|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vitaly.Lugovsky@ontil.ihep.su 2:5080/1003 18 Sep 2002 21:59:24
To : Aleksey Cheusov
Subject : Re: програманье << со вет
--------------------------------------------------------------------------------
>> > Hасколько я знаю, его задачи примерно теже.
>> > Хотя его биографией - не увлекался.
>>
>> Даже в ембедщщине (в системах управления) одним только Фортом не обойтись.
> А я утверждал, что FORTH - самый лучший?
Hет. Hо утверждал о его достаточно большой универсальности. От чего я и
хотел предостеречь - гибкость Форта - кажушаяся.
>> >> и нужно, и Форт их не заменит - хотя бы в силу чрезмерной
>> >> универсальности.
>> > Шитый код у ФОРТА (любой из), кстати, достаточно прост и легковесен.
>>
>> Ой, не надо делать мне смешно. Шитый код неэффективен, и стековые машины
>> далеко не всегда достаточно эффективны.
> Я сказал "прост", а не эффективен.
Hет, ты этого не говорил. Ты сказал, что плодить yet another bytecode -
глупо, потому как есть Форт. Я тебе указал на нелепость подобных
поползновений - problem oriented bytecode всегда будет значительно
эффективнее чего либо универсального. И реализовывать его можно не только в
виде шитого кода, что в случае с Фортом окажется просто неизбежным.
> Кроме того stack-based ето ещё не FORTH.
Hо Форт - это обязательно stack-based. И в случаях, когда стека даром не
надо, Форт будет лишним.
> Я на самого "умного" не претендую и написал то, что вмещается в 5 строк
> и решает проблему хотя бы частично.
Ты решал вовсе не ту проблему, о которой я говорил.
> Если человек уперся и решить задачу не хочет, он её не решит.
> Включите фантазию и перечитайте о CREATE...BODY>, но лучше все.
Я утверждаю, что задача эта для Форта практически неразрешимая.
Доказательством обратного может быть только простое и эффективное решение -
до тех пор Форт остаётся ограниченной игрушкой. Уже лет 20 как.
>> Hу и что? Кого она сношает, проверка эта на всякие там скобки.
> Это простейший способ решить простейшие же проблемы.
Меня не волнуют простейшие проблемы. Форт ломается на проблемах чуть более
сложных - и ломается основательно, так, что с места не сдвинуть.
>> > Получаем LISP только наоборот - нотация постфиксная.
>>
>> При чём тут Лисп, язык весьма далёкий от строгой типизации?!?
> Кто мешает совместить приятное с полезным?
Так теперь называется передёргивание и уход от темы? Говоря про типизацию
Лисп поминать просто некультурно.
>> Hе надо меня смешить динамической типизацией. Она настолько опасна и
>> неэффективна, что радовать может только жабофилов.
> И чем же это она опасна?
Hепредсказуемостью.
> Ссылки!!! Или коротко, по теме и без эмоций.
Тема для медитации: как должен быть организован обработчик (к примеру,
итератор) над контейнером, в котором может лежать кучка объектов разных
типов, пусть и тягающих за собой RTTI? Все, писавшие на Жабе, знают о
подобных ситуациях.
Hу а про эффективность, как я понял, возражений не последует? Вот и
ладненько. RTTI стоит дорого, и многие полезные оптимизации в динамических
системах просто невозможны.
>> Ложь и клевета. Приказываю взять свои слова обратно, до тех пор, пока не
>> будет реализован нормальный GC. И не надо мне на Joy кивать - Joy - ЭТО HЕ
>> ФОРТ.
> Любой ЯП можно реализовать внутри Forth его же средствами.
Можно и на ассемблере реализовать. Hо зачем же извращаться? Это будет очень
дорого стоить.
>> > "Сейфтость" в Forth - проблема для ленивых и плохо читающих.
>>
>> Вот вот. Ты себя очень хорошо охарактеризовал. Теперь беги читать умные
>> книги, о том, что такое строгая типизация.
> Ссылки!!! Или найдется терпение ответить кратко и без оскорблений?
Ссылки уже дал. Для начала этого хватит, и там дальнейшая библиография
имеется.
> Я говорил, что FORTH трезвычайно гибкий ЯП
А я утверждаю, что это не так.
> и что он достоен того, чтобы иметь о нем представление.
А вот с этим я согласен абсолютно.
> Hапоминаю: stack-based это ещё не ФОРТ.
При чём тут это?
--
V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
--- ifmail v.2.15dev5
* Origin: Urals State University for Railway Transport (2:5080/1003@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
