epsilon$ while read LINE; do echo \>"$LINE"; done < "jacem"
>Żaden język programowania nie jest mało poważny.

http://en.wikipedia.org/wiki/Esoteric_programming_la
nguage

--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|

do góry

Użytkownik "Mariusz Kruk" <M...@e...eu.org> napisał w wiadomości
news:slrnhol93n.t90.Mariusz.Kruk@epsilon.rdc.pl...
> epsilon$ while read LINE; do echo \>"$LINE"; done < "jacem"
>> Żaden język programowania nie jest mało poważny.
> http://en.wikipedia.org/wiki/Esoteric_programming_la
nguage

Brainfuck, czyli poważny język do niepoważnych zastosowań.

Inaczej - Grabowski grał Kiepskiego, z czego nie wynika, że to osoba niepoważna.
;-)

do góry

Użytkownik "jacem" <j...@1...pl> napisał w wiadomości grup
dyskusyjnych:hmb9gb$jnh$...@n...news.neostrada.pl.
..
> No dobrze, temat chyba już wyczerpany.

To jeszcze jedna prośba - padły różne propozycje - stąd moje kolejne
pytania.

Ile czasu potrzebowalibyście, aby w waszym ulubionym języku napisać program
grający w Tetris? I jak długi - według was - byłby to program?

Nie chodzi rzecz jasna o napisanie kolejnego klona Tetrisa - lecz o program,
który dysponując danymi o kolejnych klockach (tak jak człowiek) potrafiłby w
miarę sensownie układać te klocki zgodnie z regułami gry Tetris.

Nie potrzeba mi takiego programu! Ale myślę, że tego rodzaju problem nie
jest zupełnie trywialny. Chciałbym jedynie, abyśmy mieli jakieś porównanie,
coś czym moglibyśmy uzupełnić dyskusję nt. dydaktycznych języków
programowania.

slawek

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "jacem"
>>> Żaden język programowania nie jest mało poważny.
>> http://en.wikipedia.org/wiki/Esoteric_programming_la
nguage
>Brainfuck, czyli poważny język do niepoważnych zastosowań.
>
>Inaczej - Grabowski grał Kiepskiego, z czego nie wynika, że to osoba niepoważna.
>;-)

Powiedzmy, że nie do końca się zgodzę, ale nie chce mi się ciągnąć tego
tematu. :-)

--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb
`b K...@e...eu.org d'
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'

do góry

On 28 Lut, 23:58, "slawek" <s...@h...pl> wrote:
>To jeszcze jedna pro ba - pad y r ne propozycje - st d moje kolejne
>pytania.

Ta dyskusja będzie się ciągnąć w nieskończoność? :D

> Ile czasu potrzebowaliby cie, aby w waszym ulubionym j zyku napisa program
> graj cy w Tetris? I jak d ugi - wed ug was - by by to program?

Odpowiedzi nie będą miarodajne, nie wiemy przecież kto jak dobrze
pisze w "swoim ulubionym języku".
Można próbować porównać na podstawie wykonanych już testów:
http://shootout.alioth.debian.org/ czas/pamięć/ilość kodu ;)

do góry

Użytkownik "Spec" <m...@g...com> napisał w wiadomości grup
dyskusyjnych:76d1fd81-19bf-4055-bc6a-1e7147b16b81@g1
1g2000yqe.googlegroups.com...
>> Ile czasu potrzebowaliby cie, aby w waszym ulubionym j zyku napisa
>> program
>> graj cy w Tetris? I jak d ugi - wed ug was - by by to program?
>
> Odpowiedzi nie będą miarodajne, nie wiemy przecież kto jak dobrze
> pisze w "swoim ulubionym języku".

Ale to właśnie bardzo dobrze! Bo oczywiście moglibyśmy np. zrobić taki
dream-team: Aleksiej Pażytnow, Don Knuth, Thomas Cormen, Niklaus Wirth,
Bjarne Stroustrup plus Linus Torvalds i Bill Gates (jako konsultanci d/s OS)
oraz oczywiście Qurczak i A.L. ;) Jednak ciekawi mnie jaka jest
efektywność tworzenia oprogramowania w "ulubionym języku" przez
"przeciętnego dyskutanta z PCP".

Po prostu wydaje mi się, że każdy w jakiś tam - bardziej lub mniej - mętny
sposób wyobraża sobie rozmiar (w linijkach) i czas (ile dni na
zaprogramowanie) jakiego wymaga zrobienie takiego programu w języku, który
zna i lubi. Oczywiście - może się mylić! Ale to też bardzo cenna
informacja - bo jeżeli jakiś język systematycznie daje prze- lub
niedoszacowanie nakładu "robocizny" - to samo w sobie jest ciekawe.

Moim zdaniem, gdybym miał jakiś dobry pomysł na układanie klocków (zacząłbym
od podobnych rozwiązań jakie mają najprostsze programy szachowe, takie 8
hetmanów itp.), to w np. Fortranie byłoby to jakieś 200 do 500 linii (po
prostu chyba nie wytrzymałbym i zaprzestał realizacji gdy tych linii
zrobiłoby się 1000 czy 2000) - bez jakiegoś GUI itp. rzeczy. Oczywiście
program "widzi" tak jak człowiek - tzn. tylko bieżący klocek - a układać ma
w miarę dobrze - czyli nie spuszczać po random.

> Można próbować porównać na podstawie wykonanych już testów:
> http://shootout.alioth.debian.org/ czas/pamięć/ilość kodu ;)

Tylko że te testy podają czas wykonania - czyli czas jaki zajmują
obliczenia. Mi chodzi zaś o czas potrzebny na stworzenie działającego
programu w danym języku. Czyli zupełnie coś innego. Ładnie to nie zabrzmi:
"osobogodziny". ;)

Jeszcze raz - aby nie było nieporozumień - taki program jest mi do niczego
nie potrzebny. Ale uważam że jest dostatecznie "ciekawy", aby warto było
oszacować jaka byłaby pracochłonność jego stworzenia. Przy tym nie jest
ważne, w jaki sposób działałby - czy jakiś trikiem algorytmicznym, czy też
dzięki wyczerpującym sprawdzeniu wielu rozwiązań. Może jeszcze drobne
ograniczenie - tempo działania takie, aby układał jedną kostkę krócej lub
niewiele dłużej niż 1 sekundę.

slawek

do góry

Użytkownik "slawek" <s...@h...pl> napisał w wiadomości
news:hmgjms$88j$1@atlantis.news.neostrada.pl...
> Użytkownik "Spec" <m...@g...com> napisał w wiadomości grup
> dyskusyjnych:76d1fd81-19bf-4055-bc6a-1e7147b16b81@g1
1g2000yqe.googlegroups
> .com...
>>> Ile czasu potrzebowaliby cie, aby w waszym ulubionym j zyku napisa program
>>> graj cy w Tetris? I jak d ugi - wed ug was - by by to program?
>> Odpowiedzi nie będą miarodajne, nie wiemy przecież kto jak dobrze
>> pisze w "swoim ulubionym języku".
> Ale to właśnie bardzo dobrze! Bo oczywiście moglibyśmy np. zrobić taki
> dream-team: Aleksiej Pażytnow, Don Knuth, Thomas Cormen, Niklaus Wirth, Bjarne
> Stroustrup plus Linus Torvalds i Bill Gates (jako konsultanci d/s

A oni wszyscy żyją jeszcze? ;-)

do góry

Użytkownik "slawek" <s...@h...pl> napisał w wiadomości

> Moim zdaniem, gdybym miał jakiś dobry pomysł na układanie klocków
> (zacząłbym od podobnych rozwiązań jakie mają najprostsze programy
> szachowe, takie 8 hetmanów itp.), to w np. Fortranie byłoby to jakieś
> 200 do 500 linii (po prostu chyba nie wytrzymałbym i zaprzestał
> realizacji gdy tych linii zrobiłoby się 1000 czy 2000) - bez jakiegoś
> GUI itp. rzeczy. Oczywiście program "widzi" tak jak człowiek - tzn.
> tylko bieżący klocek - a układać ma w miarę dobrze - czyli nie
> spuszczać po random.

Jak myśli człowiek w trakcie takiej gry?
Sławku, grając w tetris, jaką obierasz strategię?
To pierwsze, podstawowe założenie.

Chyba bajbardziej optymalne byłoby dążenie do zapewnienia jak najbardziej
płaskiej powierzchni.
I od tego należałoby zacząć.
Mnie się prędzej nasuwa analogia do gry w kółko i krzyżyk niż szachy.


> Jeszcze raz - aby nie było nieporozumień - taki program jest mi do
> niczego nie potrzebny. Ale uważam że jest dostatecznie "ciekawy", aby
> warto było oszacować jaka byłaby pracochłonność jego stworzenia. Przy
> tym nie jest ważne, w jaki sposób działałby - czy jakiś trikiem
> algorytmicznym, czy też dzięki wyczerpującym sprawdzeniu wielu
> rozwiązań. Może jeszcze drobne ograniczenie - tempo działania takie,
> aby układał jedną kostkę krócej lub niewiele dłużej niż 1 sekundę.
> slawek

Ludzie, którzy na codzień zajmują się tworzeniem gier, na pewno dadzą
wyczerpującą odpowiedź. Przypuszczam, że tego typu problemy mają już dawno
rozpracowane.


j.

do góry

Użytkownik "jacem" <j...@1...pl> napisał w wiadomości grup
dyskusyjnych:hmglfr$cem$...@a...news.neostrada.pl
...
>> dream-team: Aleksiej Pażytnow, Don Knuth, Thomas Cormen, Niklaus Wirth,
>> Bjarne Stroustrup plus Linus Torvalds i Bill Gates (jako konsultanci d/s
>
> A oni wszyscy żyją jeszcze? ;-)

Z tego co wiem, to tak. Dlatego nie wymieniłem np. Turinga czy Dijkstry.

Czy żyje Qurczak i A.L. ? Tego nie wiem, ale chyba zauważyłbym - a może i
nie zauważyłbym?! - w każdym razie zdrowia życzę.

slawek

do góry

Użytkownik "jacem" <j...@1...pl> napisał w wiadomości grup
dyskusyjnych:hmgm9b$e7b$...@a...news.neostrada.pl
...
> Jak myśli człowiek w trakcie takiej gry?
> Sławku, grając w tetris, jaką obierasz strategię?
> To pierwsze, podstawowe założenie.

Ja tam "nie myślę" - tzn. nie stosuję jakiegoś formalnego algorytmu. Więc
raczej blado od tej strony. :)

> Chyba bajbardziej optymalne byłoby dążenie do zapewnienia jak najbardziej
> płaskiej powierzchni.
> I od tego należałoby zacząć.
> Mnie się prędzej nasuwa analogia do gry w kółko i krzyżyk niż szachy.

Kiedyś napisałem program grający w kółko i krzyżyk - algorytm był
jednolinijkowy, do dziś pamiętam:

n = (n + 1) mod 9

Sprawdza się na planszy 3x3, AI zawsze jako druga, numeracja pól jakoś tam
sobie szła. Nie wygra i nie przegra. Czysty minimax.

> Ludzie, którzy na codzień zajmują się tworzeniem gier, na pewno dadzą
> wyczerpującą odpowiedź. Przypuszczam, że tego typu problemy mają już dawno
> rozpracowane.

Zgoda, ale NIE chodzi o to aby ZROBIĆ TO - ale aby zastanowić się JAK DUŻE
TO BYŁOBY WYZWANIE.

I odpowiedź niekoniecznie nieomylna - może algorytm da się streścić w paru
linijkach? A może porządny algorytm to jakieś 10 tysięcy linii kodu? Mnie
nie interesuje, by taki napisać (bo i po co?) - ale aby zorientować się, jak
bardzo ufacie swoim ulubionym językom programowania. Jeżeli ktoś np. pisze,
że PHP jest cool - a potem nie potrafi ocenić, ile musiałby naklepać tego
PHP aby mieć "program rozwiązujący łamigłówkę Tetris" - to czy PHP jest taki
cool? Zamiast PHP podstawcie sobie inne języki, przeiterujcie.

Jeszcze jedno - zakładam że program nie musi być the best - takim "terisowym
mistrzem" - patrz Głęboko Niebieski i gra w szachy. Chodzi tylko o to, by
grał sportowo, uczciwie. Dlatego odpadają programy upuszczające klocki tak
jak są, albo upuszczające je z losowym obrotem i przemieszczeniem. Pewnym
utrudnieniem mogłoby być przesuwanie klocków tak, aby wlazły pod inne
(pozwalamy opaść w pewnym położeniu... i myk w lewo lub prawo gdy będą już
na dole) - więc załóżmy że tego robić nie wolno.

Ja bym próbował np. tak jak poniżej. Nie twierdzę, że to dobre rozwiązanie.

Przesunięć jest może 10, obroty mnożą to przez 4, symetria może zredukować.
Czyli jakieś do 40 pozycji do rozpatrzenia, powiedzmy 2^5. Typów klocków
jest może z 2^4. Stąd przewidywanie jakie przyjdą kolejne dwa (mając już
jeden) i spasowanie ich daje łącznie (2^5)^3 * (2^4)^2 = 2^23 = 8 milionów
kombinacji. To niedużo - jeżeli jeszcze uda nam się ograniczyć trochę
(usunąć te, które są ewidentnie złe, odfiltrować symetryczne). Czyli
wstawiamy klocek tak, aby optymalnie pasował - biorąc pod uwagę kolejne dwa,
których jeszcze nie ma. I od nowa.

Musimy jeszcze jakąś reprezentację mieć planszy, klocków, definicję
"optymalności" - nie mówię że to łatwe i nie jest pracochłonne.

Ale zakładam, że program ma prawo się mylić - tzn. nie musi sprawdzać
wszystkich możliwości, może używać funkcji random (jeżeli to uzasadnione).

Trzebaby pogooglać - może są jacyś entuzjaści tego typu programów. Ale nie
chodzi o sam program - lecz o zagadnienie, które: a. można zaprogramować; b.
nie jest to "typowe" programowanie
kadry-płace-excel-webmastering-cholera-wie-co; c. fajne jakieś takie wyszło.

Moim zdaniem ciekawiej jest porównywać "jak duży ma być program układający
Tetris" - niż programy "Hello, I am Jan... Jan B."

slawek

do góry