On Mon, 29 Dec 2014 19:11:29 +0100, Borneq
<b...@a...hidden.pl> wrote:
> Ale na jednym końcu są asemblery kodu maszynowego (jest jeszcze
hex;-),
> potem assemblery bajtkodu jak Javy i Net, a po drugiej stronie
pseudokod

Niżej są komputery analogowe. Wyżej jest UML.

do góry

On Tue, 30 Dec 2014 14:15:06 -0600, A.L. <a...@a...com> wrote:
> Rozumiem ze to miala byc ironia?...

Ojtam, ojtam, ...

Ivonka świetnie czyta Forth.

do góry

On Wednesday, December 31, 2014 6:40:47 PM UTC+1, slawek wrote:
> Niżej są komputery analogowe. Wyżej jest UML.

A ktoś w ogóle na poważnie, przemysłowo używa UML-a?
Ja się nie spotkałem.

w.

do góry

On Wed, 31 Dec 2014 09:47:52 -0800 (PST), Wojciech Muła
<w...@g...com> wrote:

>On Wednesday, December 31, 2014 6:40:47 PM UTC+1, slawek wrote:
>> Niżej są komputery analogowe. Wyżej jest UML.
>
>A ktoś w ogóle na poważnie, przemysłowo używa UML-a?
>Ja się nie spotkałem.
>
>w.

Ja tez nie.

Tak na marginesie, jest ksiazeczka niejakiego Fowlera, "UML
Distilled". Fowler byl zaangazowany w tworzenie UML. W wydaniu 3 jest
dosyc sceptyczny w sprawie uzytecznosci UML, w szczegolnosci roznych
cuda-nie-widy narzedzi komputerowych do UML. Jak sam przyznaje, UMLa
uzywa do poczatkowych szkicow, ktore robi na przyslowiowych
papierowych serwetkach. Ciekawa lektura, tak w ogole, ksiazke polecam
jako odtrutke gdyby ktos bym zarazony UMLizmem

A.L.

do góry

On Wednesday, December 31, 2014 8:46:59 PM UTC+1, A. L. wrote:
> On Wed, 31 Dec 2014 09:47:52 -0800 (PST), Wojciech Muła
> <> wrote:
>
> >On Wednesday, December 31, 2014 6:40:47 PM UTC+1, slawek wrote:
> >> Niżej są komputery analogowe. Wyżej jest UML.
> >
> >A ktoś w ogóle na poważnie, przemysłowo używa UML-a?
> >Ja się nie spotkałem.
> >
> >w.
>
> Ja tez nie.
>
> Tak na marginesie, jest ksiazeczka niejakiego Fowlera, "UML
> [...]
> jako odtrutke gdyby ktos bym zarazony UMLizmem

Ja tez nie uzywam, ale myslalem ze to zle.
Pozdrawiam

do góry

On Wed, 31 Dec 2014 13:46:58 -0600, A.L. <a...@a...com> wrote:
> uzywa do poczatkowych szkicow, ktore robi na przyslowiowych

Dlatego UML jest wyżej.

do góry

On Wed, 31 Dec 2014 13:46:58 -0600, A.L. <a...@a...com> wrote:
> Ja tez nie.

Argument "nie używam i dlatego nie jest [dla mnie] przydatne" ?! LOL.

UML nie jest dla koderów. Klepaczom do niczego się nie przyda.

do góry

jedna z moich skinek do jezyka c
(ostatnio opracowywane (jako 'opcja'))



static

((dbl) summ value taken for controll)

calculate mandelbrot for test (

(int) CLIENT SIZE X,
(int) CLIENT SIZE Y,
(dbl) paint map centre x,
(dbl) paint map centre y,
(dbl) paint map size x ,
(int) max number of iterations)
{

setup variables:

(dbl) paint map size y = paint map size x * CLIENT SIZE Y / CLIENT SIZE X

(dbl) per pixel delta x = paint map size x / CLIENT SIZE X
(dbl) per pixel delta y = paint map size y / CLIENT SIZE Y

(dbl) left top point x = paint map centre x - paint map size x * 0.5 + per pixel
delta x * 0.5
(dbl) left top point y = paint map centre y - paint map size x * 0.5 + per pixel
delta y * 0.5 ;


loop thru pixels:

for (CLIENT SIZE Y) j:
(dbl) c point imaginary = left top point y + j * per pixel delta y

for (CLIENT SIZE X) i:
(dbl) c point real = left top point x + i * per pixel delta x

fire point calculation:
(int) n = calculate n for mandelbrot escape ( c point real, c point
imaginary, max number of iterations )

summ value taken for controll += n

set pixel in client area (i ,j, palette [n]) ;
;
;

return summ value taken for controll
}

do góry

W dniu sobota, 3 stycznia 2015 19:50:22 UTC+1 użytkownik firr napisał:
> jedna z moich skinek do jezyka c
> (ostatnio opracowywane (jako 'opcja'))
>
>
>
> static
>
> ((dbl) summ value taken for controll)
>
> calculate mandelbrot for test (
>
> (int) CLIENT SIZE X,
> (int) CLIENT SIZE Y,
> (dbl) paint map centre x,
> (dbl) paint map centre y,
> (dbl) paint map size x ,
> (int) max number of iterations)
> {
>
> setup variables:
>
> (dbl) paint map size y = paint map size x * CLIENT SIZE Y / CLIENT SIZE X
>
> (dbl) per pixel delta x = paint map size x / CLIENT SIZE X
> (dbl) per pixel delta y = paint map size y / CLIENT SIZE Y
>
> (dbl) left top point x = paint map centre x - paint map size x * 0.5 + per
pixel delta x * 0.5
> (dbl) left top point y = paint map centre y - paint map size x * 0.5 + per
pixel delta y * 0.5 ;
>
>
> loop thru pixels:
>
> for (CLIENT SIZE Y) j:
> (dbl) c point imaginary = left top point y + j * per pixel delta y
>
> for (CLIENT SIZE X) i:
> (dbl) c point real = left top point x + i * per pixel delta x
>
> fire point calculation:
> (int) n = calculate n for mandelbrot escape ( c point real, c point
imaginary, max number of iterations )
>
> summ value taken for controll += n
>
> set pixel in client area (i ,j, palette [n]) ;
> ;
> ;
>
> return summ value taken for controll
> }

ps moje czesciowe wnisoki zwiazane z tym przykladem i czytelnoscia byly np takie ze
dlugie nazwy sa brdziej informacyjne ale zarazem wolniej czytelne (czyli bardziej ale
wolnie ;/ natomiast krotkie na odwrót : mniej ale szybciej ;/) (y a w n)

do góry

On 29/12/2014 19:19, g...@g...com wrote:
> Również wokół języków funkcjonują pewne kultury, które w różnym
> stopniu przywiązują wagę do czytelności programów. Na przykład
> perl jest językiem, który w samym swoim projekcie przemyca założenie,
> że można używać tajemniczych sekwencji, których znaczenie jest
> znane tylko dla wtajemniczonych.
>
> Jeżeli idzie o języki, których kultury w dużym stopniu wspierają
> piśmienność (czyli ideę, że kod ma nie tylko być wykonywany, ale
> przede wszystkim czytany), to należą do nich Python (określany
> niekiedy mianem "wykonywalnego pseudokodu"), Haskell oraz Scheme,

O Haskellu można dużo ciekawych rzeczy powiedzieć, ale żeby jako język,
albo przez swoją kulturę wspierał/wymuszał czytelność programu, to czy
ja wiem? Dla ciebie czytelna jest np. nazwa funkcji liftM2 albo operator
<*>?

do góry