W dniu 2011-11-15 17:18, A.L. pisze:
> On Tue, 15 Nov 2011 08:01:50 -0800 (PST), Maciej Sobczak
> <s...@g...com> wrote:
>
>> On Nov 15, 3:18 pm, Jacek Czerwinski<x...@...z.pl> wrote:
>>
>>> Gdzie się dostrzega - jak już cytujesz ksiazki - źródło niewykonalności?
>>> jest to
>>> a) matematycznie niewykonalne
>>> b) nikt nie ma w tym interesu (jak nie wiadomo o co chodzi ...)
>>> c) ...
>>
>> Masz kluczowy zwrot "wygenerować kod aplikacji".
>> Problem w tym, że aplikacja zwykle coś robi i trzeba to jakoś
>> wyspecyfikować - tzn. opisać, co ona robi, żeby było *dokładnie*
>> wiadomo, co wygenerować.
>>
>> Istnieją świetnie działające narzędzia do tego i nazywa się je
>> językami programowania.
>
> Tylko ze w wielu wypadkach nei sa one "swietne". Wrecz przciwnie, sa
> do niczego. Wymagaja opisu nie tylko CO aplikacja ma robic, ale i JAK,
> i to z najdrobniejszymi szczegolami owego JAK. Wysilki ida w kierunku
> posiadania narzeczi opisujacych CO. Tylko i wylacznie. JAK powinno byc
> zautomatyzowane

Świetnym przypadkiem takiego podejścia jest "język" HQ9+ 8-)
http://esoteric.voxelperfect.net/wiki/HQ9

Wszystko fajnie, tylko stawianie granicy między CO i JAK wymaga
ustalenia pewnych podstawowych reguł (i wbudowania je
w język/biblioteki), które mówią JAK. W tak zdefiniowanym języku będzie
wystarczyło powiedzieć CO. Ale to oddzielne dla każdej dziedziny, co
gorsza szybko okazuje się, że dostępne klocki nie pozwalają na
zbudowanie CO[N+1], choć pozwalały na CO[0]..CO[N]. No i taki HQ9+
trzeba rozszerzyć do HQ9+B http://esoteric.voxelperfect.net/wiki/HQ9_B

Nie da się zbudować języka programowania, w którym wszystkie możliwe CO
będzie można opisać bez wchodzenia w szczegóły JAK.

--
Paweł Kierski
n...@p...net