🚀 go-pugleaf

Dnia 16-02-2011 o 13:05:14 Maciej Pilichowski  
<Pilichowski.MaciejSkasujTo@gmail.com> napisał(a):

> Hej,
>
>   Ponoc to makra to cale zlo. Zalozmy.
>
> W C# mamy anonimowe tuple z nazwanymi polami oraz nazwane tuple z tak
> naprawde anonimowymi polami.
>
> Brak nazwanych tupli z nazwanymi polami jest znanym problem i byc moze
> w nowych wersjach C# sie go doczekamy.
>
> Gdybysmy jednak mieli makra, to podobnie jak w C++ moglibysmy sami to
> napisac i uzywac od dluzszego czasu piszac , np.
>
> DefTuple2(Punkt,int,WspX,int,WspY);
>
> Czekam na kontre od przeciwnikow ("makra to zlo") jak stworza podobna
> konstrukcje w C#. Czy tez beda czekali na ten feature, az MS go
> wprowadzi? A moze nazwane tuple z nazwanymi polami to tez cale zlo?
> ;-)
>
> milego dnia, hej

Ja poproszę o kod tego super marka DefTuple2.

-- 
3P

On Wed, 16 Feb 2011 13:05:14 +0100, Maciej Pilichowski wrote:
> Gdybysmy jednak mieli makra, to podobnie jak w C++ moglibysmy sami to
> napisac i uzywac od dluzszego czasu piszac , np.
> 
> DefTuple2(Punkt,int,WspX,int,WspY);
> 
> Czekam na kontre od przeciwnikow ("makra to zlo") jak stworza podobna
> konstrukcje w C#. Czy tez beda czekali na ten feature, az MS go
> wprowadzi? A moze nazwane tuple z nazwanymi polami to tez cale zlo?
> ;-)

Podobna konstrukcja w C#:

public class Punkt
{
  public int WspX { get; set; }
  public int WspY { get; set; }
}

Instrukcja obsługi:
class<tab><tab>Punkt<enter>
prop<tab><tab>int<tab>WspX<enter>
prop<tab><tab>int<tab>WspX<enter>

I od razu każdy widzi co mam na myśli, włacznie
z kimś kto przychodzi pierwszy raz do firmy i nie ma 
using Maciej.Pilichowski.Framework.Magic.Macros.And.Aliases;
w małym palcu. 

Do tego jak się uprę to dopisze sobie w, literalnie, 3 minuty
snippeta który mi to wygeneruje z "pair<tab><tab>" z 
placeholderami na identyfikatory.

Jak się jeszcze bardziej uprę to dopisze do VS Custom Tool
który będzie mi generował Code-Behind z plików w jakims
briefowym formacie.

Ale spójrzmy sobie prawdzie w oczy, to jest 10 sekund
"ręcznej roboty, olaboga bez makr!". Jeżeli to powoduje
u kolegi aż tak wielkie problemy nie do obejścia, a
jednocześnie tak wielkie podniecenie preprocesorem 
z C/C++, to ja współczuję z całego serca.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

Dnia 16-02-2011 o 13:51:46 Łukasz 'Maly' Ostrowski <maly@usunnemo.pl>  
napisał(a):

> On Wed, 16 Feb 2011 13:05:14 +0100, Maciej Pilichowski wrote:
>> Gdybysmy jednak mieli makra, to podobnie jak w C++ moglibysmy sami to
>> napisac i uzywac od dluzszego czasu piszac , np.
>>
>> DefTuple2(Punkt,int,WspX,int,WspY);
>>
>> Czekam na kontre od przeciwnikow ("makra to zlo") jak stworza podobna
>> konstrukcje w C#. Czy tez beda czekali na ten feature, az MS go
>> wprowadzi? A moze nazwane tuple z nazwanymi polami to tez cale zlo?
>> ;-)
>
> Podobna konstrukcja w C#:
>
> public class Punkt
> {
>   public int WspX { get; set; }
>   public int WspY { get; set; }
> }
>
> Instrukcja obsługi:
> class<tab><tab>Punkt<enter>
> prop<tab><tab>int<tab>WspX<enter>
> prop<tab><tab>int<tab>WspX<enter>
>
> I od razu każdy widzi co mam na myśli, włacznie
> z kimś kto przychodzi pierwszy raz do firmy i nie ma
> using Maciej.Pilichowski.Framework.Magic.Macros.And.Aliases;
> w małym palcu.
>
+1

Nie tylko widać na tym przykładzie, że makra nie są potrzebne, ale że
idiotycznie stosowane (jak powyżej) tylko wszystko utrudniają.

-- 
3P

Maciej Pilichowski wrote:
> Hej,
>
>  Ponoc to makra to cale zlo. Zalozmy.
>
> W C# mamy anonimowe tuple z nazwanymi polami oraz nazwane tuple z tak
> naprawde anonimowymi polami.
>
> Brak nazwanych tupli z nazwanymi polami jest znanym problem i byc moze
> w nowych wersjach C# sie go doczekamy.

Ja bardzo przepraszam ale móglbys mi wytlumaczyc czym sie róznia "nazwane 
tuple z nazwanymi polami" od zwyklej struktury? Hm... tuple to tak wlasciwie 
termin matematyczny a jak sie matematycy biora za programowanie to mnie 
osobiscie zapala sie lampka ostrzegawcza. :-)
yamma 

> W C# mamy anonimowe tuple z nazwanymi polami

mamy

> oraz nazwane tuple z tak naprawde anonimowymi polami.

mamy

> DefTuple2(Punkt,int,WspX,int,WspY);

podobnie jak Koledzy nie widze czym to mialoby przewyzszac "reczna" pelna 
definicje, ale podpowiadam jak to osiagnac podobnie jak w C++ - otóz system 
"makr" daja Ci tak naprawde generatory kodu typu CodeSmith czy T4. jesli w 
skrypcie buildowania Twojego kodu najpierw uruchamia sie generator kodu, a 
dopiero potem kompilator, to w sumie nie wiem czy rózni sie to jakos 
obserwowalnie od fazy rozwijania makrodefinicji i fazy kompilacji w 
kompilatorze c++.

> Czekam na kontre od przeciwnikow ("makra to zlo") jak stworza podobna
> konstrukcje w C#. Czy tez beda czekali na ten feature, az MS go
> wprowadzi? A moze nazwane tuple z nazwanymi polami to tez cale zlo?

dlaczego to mialoby byc zlo? nie ma nic zlego w posiadaniu w kodzie 100 
nazwanych klas z nazwanymi polami.

pozdrawiam
Wiktor Zychla 

On Wed, 16 Feb 2011 15:21:07 +0100, Wiktor Zychla wrote:
>> Czekam na kontre od przeciwnikow ("makra to zlo") jak stworza podobna
>> konstrukcje w C#. Czy tez beda czekali na ten feature, az MS go
>> wprowadzi? A moze nazwane tuple z nazwanymi polami to tez cale zlo?
> 
> dlaczego to mialoby byc zlo? nie ma nic zlego w posiadaniu w kodzie 100 
> nazwanych klas z nazwanymi polami.

Maciej referuje do "makr będacych złem" w nawiązaniu do mojego
sformułowania zapożyczonego z powszechnie znanego:

http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.5

A fragment z krotkami to jest celowy exaggeration zapewne ;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

On Wed, 16 Feb 2011 15:21:07 +0100, "Wiktor Zychla"
<wzychla@nospam.com> wrote:

>> DefTuple2(Punkt,int,WspX,int,WspY);
>
>podobnie jak Koledzy nie widze czym to mialoby przewyzszac "reczna" pelna 
>definicje,

Problem w tym, ze jesli piszesz program, ktory robi cos wiecej niz
fakturowanie i magazynowanie to Twoj kod (ten, ktory czytasz) jest
zawalony definicjami, ktore nic nie wnosza. A musisz to przegladac
przy analizie kodu.

> otóz system 
>"makr" daja Ci tak naprawde generatory kodu typu CodeSmith czy T4. 

Nie chodzi o to, zebym ja mniej pisal -- tylko o to, zebym ja mniej
czytal. Mam sie skupic na meritum.

Co prawda to nie problem makr, ale obejrzyj kod generowany przez
SQLMetala -- objetosc jest porazajaca mimo, ze tak naprawde to hiper
prosta konstrukcja -- przyjecie wartosci i wyslanie eventow.

milego dnia, hej
-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On Wed, 16 Feb 2011 15:21:07 +0100, "Wiktor Zychla"
<wzychla@nospam.com> wrote:

>podobnie jak Koledzy nie widze czym to mialoby przewyzszac "reczna" pelna 
>definicje, 

Rozwine moze. Kiedy powiem Ci slowo "wektor" to wiesz, ze np. mozna w
tym kontekscie mowic o normalizacji, o dlugosci, mozna policzyc
iliczony skalarny, dodac 2 wektory. Zgadza sie?

Nie za bardzo wiesz co mialoby oznaczac, ze jeden wektor jest mniejszy
od drugiego i to tez sie zgadza.

Wiec jesli napisze Wektor w kodzie, to juz masz wiedze o nim na
podstawie nie analizy kodu, ale na podstawie wiedzy o wektorze.


Jesli masz mechanizm tworzenia klas-rekordow (tupli) to kazde uzycie
takiego mechanzmu daje pewne gwarancje, ktore przydadza Ci sie jako
programiscie za lat 5, 10. Bo wracajac do kodu widzisz 

DefTuple...

i juz wiesz czego sie spodziewac, jakie operacje mozna wykonac. Nie
musisz nic doczytywac, bo masz GWARANCJE.

To samo wyrzezbione za kazdym razem z reki (lub z automatu) nie daje
ZADNEJ gwarancji, co najwyzej mozesz napisac

/// ta klasa to tak naprawde tuple
public class Moja Klasa...

Przy wiekszych projektach i prowadzonych dluzej ja jednak doceniam
gwarancje. To, ze to nie komentarze trzymaja wszystko w ryzach a sam
kod.

>dlaczego to mialoby byc zlo? nie ma nic zlego w posiadaniu w kodzie 100 
>nazwanych klas z nazwanymi polami.

W pelni rozwinietych? I owszem, jest. Pielegnacja kodu robi sie mocno
czasochlonna. Vide wyzej. 

Co prawda to nie dowod na cokolwiek, ale Tuple w Net40 nie zostalo
wprowadzone bo sie nudzilo programistom. 

milego dnia, hej
-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On Wed, 16 Feb 2011 15:21:07 +0100, "Wiktor Zychla"
<wzychla@nospam.com> wrote:

>podobnie jak Koledzy nie widze czym to mialoby przewyzszac "reczna" pelna 
>definicje, 

PS. Ok, juz koniec "znecania sie".

Po co nam szablony? Przeciez zamiast pisac Dictionary<string,int>
mozna byloby wywolac albo jakis generator kodu, albo po prostu uzyc
snippeta, aby w miejscu, w ktorym potrzebujemy wygenerowal nam pelna
klase (skonkretyzowana juz) Dictionary dla stringa i inta --
DictionaryStringInt (mniejsza o nazwe).

To nie zlosliwosc z mojej strony, tylko pokazuje na przykladzie tego
co juz jest w C# jak jest to pozyteczne -- nie istnienie Dictionary
;-) ale mechanizmow, ktore pozwalaja "zwinac" byty nizszego rzedu w
krotka, zwarta KONCEPCJE wyzszego rzedu.

I operowanie koncepcjami najwyzszego rzedu adekwatnego do problemu
jest przydatne (to moje, ale nie tylko, zdanie).

milego dnia, hej


-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

> I operowanie koncepcjami najwyzszego rzedu adekwatnego do problemu
> jest przydatne (to moje, ale nie tylko, zdanie).

ten przyklad byl zupelnie niepotrzebny. rzeczywiscie sie "znecasz" z mojego 
pytania wyciagajac zupelnie gdzie indziej idace wnioski.

absolutnie bowiem zgadzam sie z tym co piszesz powyzej jako z pewna regula 
OGÓLNA. moje pytanie dotyczylo konkretnego przypadku, tych Twoich nazwanych 
par z nazwanymi polami, a nie podwazania sensu istnienia "koncepcji wyzszego 
rzedu" w ogólnosci. moze po prostu nie wyczulem, ze nie chodzi Ci konkretnie 
o te pary, tylko o mechanizm ogólny, stad to pytanie.

to na co zwracam Twoja uwage, to to, ze nie dostrzegasz mozliwosci uzyskania 
takiego samego efektu INNYMI srodkami. bardzo przywiazales sie do tego, ze 
masz te makra "w jezyku". a czymze innym jest mechanizm szablonów generatora 
kodu? szablony dokladnie tworzy sie w TYM samym jezyku programowania, 
szablon ma czesc deklaratywna, która ewaluuje sie "jak jest" i czesc 
imperatywna, napisana w C#/VB czy czymtam chcesz, która wykonuje sie podczas 
generowania. mozesz miec swój szablon DefTuple i w jednym miejscu napisane 
ile razy chcesz go wywolac. a to, ze pliki z tymi definicjami nie beda mialy 
rozszerzenia *.cs i nie bedzie ich przetwarzal kompilator? czy to tak 
naprawde ma znaczenie?

Nie przekonasz mnie chyba latwo, ze rozwijanie w pierwszym kroku buildowania 
projektu makra napisanego w T4/CodeSmith rózni sie czyms od rozwijania 
makrodefinicji C++. w obu przypadkach zarówno ilosc kodu do napisania jak i 
do czytania bedzie podobna, z dokladnoscia do skladni. a skladnia makr w C++ 
tez nie jest elementem jezyka jako takiego, tylko jezyka dla preprocesora.

pozdrawiam
Wiktor Zychla 

Witam,

widzę, że kolega napisał tego posta na fali zafascynowania jakimś tam
narządem
i pewnie z wypiekami na twarzy jak w momencie wyświetlenia pierwszego
'hello world'.

> Problem w tym, ze jesli piszesz program, ktory robi cos wiecej niz
> fakturowanie i magazynowanie to Twoj kod (ten, ktory czytasz) jest
> zawalony definicjami, ktore nic nie wnosza. A musisz to przegladac
> przy analizie kodu.

Jak to? Tzn, że piszesz kod, który jest nieużywany w projekcie
(niepotrzebny)?

> Co prawda to nie problem makr, ale obejrzyj kod generowany przez
> SQLMetala -- objetosc jest porazajaca mimo, ze tak naprawde to hiper
> prosta konstrukcja -- przyjecie wartosci i wyslanie eventow.

Ja jestem zwolennikiem nadmiaru, który samemu można usunąć niż
doklepywać ręcznie.

Przykładem może być MyGeneration pod którego jest także szablon
generowania kodu dla NHibernate'a.
Zmodyfikowałem go, aby dodatkowo do każdej właściwości w klasie
dodawał zakomentowane atrybuty dla WCFa.

Taka nadmiarowość się przydaje, ponieważ dla mnie łatwiej jest
nacisnąć dwa razy del przy komentarzu niż klepać od nowa
[DataMember]. Zwyczajna oszczędność czasu.

--
Pozdro,
 Maćko

W dniu 2011-02-16 14:43, yamma pisze:
> Ja bardzo przepraszam ale móglbys mi wytlumaczyc czym sie róznia
> "nazwane tuple z nazwanymi polami" od zwyklej struktury? Hm... tuple to
> tak wlasciwie termin matematyczny a jak sie matematycy biora za
> programowanie to mnie osobiscie zapala sie lampka ostrzegawcza. :-)
A dlaczego ta lampka się zapala, że tak spytam całkowicie 
niezobowiązująco? :)

Pozdrawiam,
   Wit

W dniu 2011-02-17 06:46, Maciej Pilichowski pisze:
> On Wed, 16 Feb 2011 15:21:07 +0100, "Wiktor Zychla"
> <wzychla@nospam.com>  wrote:
>
>>> DefTuple2(Punkt,int,WspX,int,WspY);
>>
>> podobnie jak Koledzy nie widze czym to mialoby przewyzszac "reczna" pelna
>> definicje,
>
> Problem w tym, ze jesli piszesz program, ktory robi cos wiecej niz
> fakturowanie i magazynowanie to Twoj kod (ten, ktory czytasz) jest
> zawalony definicjami, ktore nic nie wnosza. A musisz to przegladac
> przy analizie kodu.
>
Dlatego języki deklaratywne to przyszłość. :)

Pozdrawiam,
   Wit

Wit Jakuczun wrote:
> W dniu 2011-02-16 14:43, yamma pisze:
>> Ja bardzo przepraszam ale móglbys mi wytlumaczyc czym sie róznia
>> "nazwane tuple z nazwanymi polami" od zwyklej struktury? Hm... tuple
>> to tak wlasciwie termin matematyczny a jak sie matematycy biora za
>> programowanie to mnie osobiscie zapala sie lampka ostrzegawcza. :-)
> A dlaczego ta lampka się zapala, że tak spytam całkowicie
> niezobowiązująco? :)

Bo kiedyś miałem do czynienia z softem pisanym przez absolwentów matematyki. 
Obsługa tego softu nie miała nic wspólnego z intuicyjnością i przypominała 
łapanie się prawą ręką za lewe ucho. Ja generalnie uważam, że tworzenie 
algorytmów wyłącznie przy pomocy matematycznych definicji i wzorów bardzo 
często prowadzi na manowce. Głupi przykład z obracającym się kołem: 
matematyk zrobi to korzystając z funkcji trygonometrycznych, niematematyk 
namaluje w Paincie kilkanaście obrazków koła i będzie je animował. W 
pierwszym przypadku komputer będzie wył od obliczeń, w drugim płynnie 
obracał kółkiem.
yamma 

W dniu 2011-02-17 13:15, yamma pisze:
>>> to tak wlasciwie termin matematyczny a jak sie matematycy biora za
>>> programowanie to mnie osobiscie zapala sie lampka ostrzegawcza. :-)
>> A dlaczego ta lampka się zapala, że tak spytam całkowicie
>> niezobowiązująco? :)
>
> Ja generalnie
> uważam, że tworzenie algorytmów wyłącznie przy pomocy matematycznych
> definicji i wzorów bardzo często prowadzi na manowce. Głupi przykład z
> obracającym się kołem: matematyk zrobi to korzystając z funkcji
> trygonometrycznych, niematematyk namaluje w Paincie kilkanaście obrazków
> koła i będzie je animował. W pierwszym przypadku komputer będzie wył od
> obliczeń, w drugim płynnie obracał kółkiem.
No jeśli o takich algorytmach jak powyżej jest mowa to rzeczywiście 
matematyk nie będzie mógł rozwinąć skrzydeł. Chociaż ciągle nie rozumiem 
co takiego jest w matematykach, że nie byliby w stanie użyć Paint'a?

Pozdrawiam,
    Wit

Wit Jakuczun wrote:
> W dniu 2011-02-17 13:15, yamma pisze:
>>>> to tak wlasciwie termin matematyczny a jak sie matematycy biora za
>>>> programowanie to mnie osobiscie zapala sie lampka ostrzegawcza. :-)
>>> A dlaczego ta lampka się zapala, że tak spytam całkowicie
>>> niezobowiązująco? :)
>>
>> Ja generalnie
>> uważam, że tworzenie algorytmów wyłącznie przy pomocy matematycznych
>> definicji i wzorów bardzo często prowadzi na manowce. Głupi przykład
>> z obracającym się kołem: matematyk zrobi to korzystając z funkcji
>> trygonometrycznych, niematematyk namaluje w Paincie kilkanaście
>> obrazków koła i będzie je animował. W pierwszym przypadku komputer
>> będzie wył od obliczeń, w drugim płynnie obracał kółkiem.
> No jeśli o takich algorytmach jak powyżej jest mowa to rzeczywiście
> matematyk nie będzie mógł rozwinąć skrzydeł. Chociaż ciągle nie
> rozumiem co takiego jest w matematykach, że nie byliby w stanie użyć
> Paint'a?

Chodzi o sposób myślenia. Mnie jest teraz ciężko podac jakiś przykład 
takiego softu ale rękę matematyka naprawdę od razu widać. To jest pewien 
specyficzny sposób tworzenia wszelkiej maści workflowów jakie są związane z 
funkcjonalnościami w aplikacjach. Jeśli matematyk używa Painta to ja również 
nie mam nic przeciwko temu, problem pojawia się jak matematyk zaczyna używać 
matematyki. A są tacy. Tacy... matematyczni nerdowie. :-)
yamma 

yamma wrote:
> Wit Jakuczun wrote:

>> No jeśli o takich algorytmach jak powyżej jest mowa to rzeczywiście
>> matematyk nie będzie mógł rozwinąć skrzydeł. Chociaż ciągle nie
>> rozumiem co takiego jest w matematykach, że nie byliby w stanie użyć
>> Paint'a?
>
> Chodzi o sposób myślenia. Mnie jest teraz ciężko podac jakiś przykład
> takiego softu ale rękę matematyka naprawdę od razu widać. To jest
> pewien specyficzny sposób tworzenia wszelkiej maści workflowów jakie
> są związane z funkcjonalnościami w aplikacjach. Jeśli matematyk używa
> Painta to ja również nie mam nic przeciwko temu, problem pojawia się
> jak matematyk zaczyna używać matematyki. A są tacy. Tacy...
> matematyczni nerdowie. :-)

O, coś takiego przyszło mi do głowy: z prostej operacji zapisu dokumentu do 
pliku matematyk najpierw zrobi układ równań z, powiedzmy, 3 niewiadomymi i 
każe użytkownikowi takie równania rozwiazać. :-)
yamma 

> No jeśli o takich algorytmach jak powyżej jest mowa to rzeczywiście
> matematyk nie będzie mógł rozwinąć skrzydeł. Chociaż ciągle nie rozumiem
> co takiego jest w matematykach, że nie byliby w stanie użyć Paint'a?

Tu nie chodzi o to, że matematyk nie jest w stanie użyć Painta.
Konstrukcja Painta jest zbliżona do konstrukcji cepa więc napewno
matematyk podołałby takiemu wyzwaniu.
Chodzi o inne podejście matematyka do zagadnienia i inne przez
programistę, który nie jedne zęby zjadł przy projekcie.

Matematyk podejdzie do problemu w sposób mu najlepiej znany czyli bach
wzorek wypluje parę sinusów zrobi pętelkę i mamy okrąg.
Programista natomiast prawdopodobnie też o tym pomyśli, ale możliwe że
zajdzie problem z innej strony nie matematycznej, która
prowadzi do tego samego wyniku w krótszym czasie i może wydajniej.

Próbowałem jakiś czas temu brać udział w Potyczkach Algorytmicznych i
zadowolony wysłałem rozwiązanie pewnego zadania.
Okazało się, że dostałem tylko 1/3 punktów ze względu na to, że
algorytm nie przeszedł 2/3 testów wydajności.
Konkurs tak naprawdę wyłania najlepszego matematyka, który przypadkiem
umie pisać proste pętle i zna podstawową składnie C++, javy, C
(sharp niestety jest niegodny). Szacun oczywiście dla zwycięscy tych
zawodów, ale kolega powiedział mi co taki zwycięzca
z zacięciem programisty jest wart, oczywiście świetnie sprawdza się w
roli tworzenia złożonych wydajnych algorytmów,
ale każ mu zrobić coś użytecznego. No i tu już są schody, bo matematyk
potrafi tak skomplikować prosty program, że zrobienie go
zajmie mu to dłużej niż programiście, program będzie miał i tak grację
wozu z węglem.

W dniu 2011-02-17 14:54, Macko pisze:
> Chodzi o inne podejście matematyka do zagadnienia i inne przez
> programistę, który nie jedne zęby zjadł przy projekcie.
>
Zrobiłeś założenie, że matematyk jest żółtodziobem a programista 
(rozumiem, że nie matematyk) ma zajebiste doświadczenie. Dla równowagi, 
proponuję przyjąć, że zarówno matematyk jak i programista są 
doświadczeni w dostarczaniu rozwiązań w szeroko pojętym biznesie.

> Programista natomiast prawdopodobnie też o tym pomyśli, ale możliwe że
> zajdzie problem z innej strony nie matematycznej, która
> prowadzi do tego samego wyniku w krótszym czasie i może wydajniej.
>
Ok, żeby uporządkować rozmowę. Yamma pisał, że "Ja generalnie uważam, że 
tworzenie algorytmów wyłącznie przy pomocy matematycznych definicji i 
wzorów bardzo często prowadzi na manowce.".
Ponieważ piszesz, że do problemów można podchodzić od strony nie 
matematycznej to mam pytanie: od jakiej strony należy podchodzić do 
tworzenia algorytmów aby nie wleźć na manowce?

> Próbowałem jakiś czas temu brać udział w Potyczkach Algorytmicznych i
> zadowolony wysłałem rozwiązanie pewnego zadania.
> Okazało się, że dostałem tylko 1/3 punktów ze względu na to, że
> algorytm nie przeszedł 2/3 testów wydajności.
No to po prostu źle rozwiązałeś zadanie.

Pozdrawiam,
   Wit

W dniu 2011-02-17 13:15, yamma pisze:
>> A dlaczego ta lampka się zapala, że tak spytam całkowicie
>> niezobowiązująco? :)
>
> Ja generalnie
> uważam, że tworzenie algorytmów wyłącznie przy pomocy matematycznych
> definicji i wzorów bardzo często prowadzi na manowce.
Kompletnie nie zgadzam się z tym zdaniem. Możesz powiedzieć w jaki inny 
sposób można podchodzić do tworzenia algorytmów?

Pytam zupełnie poważnie. Zawodowo zajmuję się tworzeniem algorytmów. 
Jestem matematykiem. :) Co gorsze wielokrotnie pomagałem programistom 
(nie matematykom) zrobić rozwiązanie, które działa wg założeń i do tego 
wydajnie. Moje podejście jest dokładnie takie jak napisałeś. Tworzę 
definicje i wzory. Nie mniej jednak chętnie bym poznał inne podejścia, 
szczególnie, że mogłyby być lepsze.

Pozdrawiam,
   Wit

Dnia 17-02-2011 o 07:02:01 Maciej Pilichowski  
<Pilichowski.MaciejSkasujTo@gmail.com> napisał(a):

> On Wed, 16 Feb 2011 15:21:07 +0100, "Wiktor Zychla"
> <wzychla@nospam.com> wrote:
>
>> podobnie jak Koledzy nie widze czym to mialoby przewyzszac "reczna"  
>> pelna
>> definicje,
>
> Rozwine moze. Kiedy powiem Ci slowo "wektor" to wiesz, ze np. mozna w
> tym kontekscie mowic o normalizacji, o dlugosci, mozna policzyc
> iliczony skalarny, dodac 2 wektory. Zgadza sie?
>
> Nie za bardzo wiesz co mialoby oznaczac, ze jeden wektor jest mniejszy
> od drugiego i to tez sie zgadza.
>
> Wiec jesli napisze Wektor w kodzie, to juz masz wiedze o nim na
> podstawie nie analizy kodu, ale na podstawie wiedzy o wektorze.
>
>
> Jesli masz mechanizm tworzenia klas-rekordow (tupli) to kazde uzycie
> takiego mechanzmu daje pewne gwarancje, ktore przydadza Ci sie jako
> programiscie za lat 5, 10. Bo wracajac do kodu widzisz
>
> DefTuple...
>
> i juz wiesz czego sie spodziewac, jakie operacje mozna wykonac. Nie
> musisz nic doczytywac, bo masz GWARANCJE.
>
> To samo wyrzezbione za kazdym razem z reki (lub z automatu) nie daje
> ZADNEJ gwarancji, co najwyzej mozesz napisac
>
> /// ta klasa to tak naprawde tuple
> public class Moja Klasa...
>
> Przy wiekszych projektach i prowadzonych dluzej ja jednak doceniam
> gwarancje. To, ze to nie komentarze trzymaja wszystko w ryzach a sam
> kod.
>
>> dlaczego to mialoby byc zlo? nie ma nic zlego w posiadaniu w kodzie 100
>> nazwanych klas z nazwanymi polami.
>
> W pelni rozwinietych? I owszem, jest. Pielegnacja kodu robi sie mocno
> czasochlonna. Vide wyzej.
>
Nonsens. Jeżeli w tych klasach jest coś więcej niż w tych twoich tuplach
to jest tam bo jest potrzebne. Jak jest to co w twoich tuplach (czyste  
DTO),
żadne obiekty, to nie ma czego pielęgnować.

> Co prawda to nie dowod na cokolwiek, ale Tuple w Net40 nie zostalo
> wprowadzone bo sie nudzilo programistom.

A mógłbyś uraczyć linkami do artykułów, gdzie inne osoby również narzekają
na brak tych tupli? Pisałeś wcześniej, że nie tylko tobie ich brakuje.

A jak już naprawdę czegoś takiego potrzebujesz to masz T4 i możesz zrobić
sobie swojego DSL-a.

-- 
3P

Wit Jakuczun wrote:
> W dniu 2011-02-17 13:15, yamma pisze:
>>> A dlaczego ta lampka się zapala, że tak spytam całkowicie
>>> niezobowiązująco? :)
>>
>> Ja generalnie
>> uważam, że tworzenie algorytmów wyłącznie przy pomocy matematycznych
>> definicji i wzorów bardzo często prowadzi na manowce.
> Kompletnie nie zgadzam się z tym zdaniem. Możesz powiedzieć w jaki
> inny sposób można podchodzić do tworzenia algorytmów?

Wiesz, mnie generalnie chodzi o to, że tworzone przez matematyków algorytmy 
wymuszają kompletnie niestrawne dla użytkownika interfejsy. Tak jak pisałem, 
często zamiast zwyczajnego "File->Open" uzytkownik musi rozwiązywać układ 
równań z 3 niewiadomymi. Zastanawiające jest to, że takie zachowania ja 
obserwuję najczęściej w naszych rodzimych produkcjach.

> Pytam zupełnie poważnie. Zawodowo zajmuję się tworzeniem algorytmów.
> Jestem matematykiem. :) Co gorsze wielokrotnie pomagałem programistom
> (nie matematykom) zrobić rozwiązanie, które działa wg założeń i do
> tego wydajnie. Moje podejście jest dokładnie takie jak napisałeś.
> Tworzę definicje i wzory. Nie mniej jednak chętnie bym poznał inne
> podejścia, szczególnie, że mogłyby być lepsze.

To zależy jak jesteś doświadczony. Wiele wzorców, metodologii nabywa się nie 
na studiach tylko po kilku latach pracy. Niestety, u nas polityka kadrowa w 
firmach polega na zatrudnianiu studentów 3, 4 roku bo nie trzeba za nich 
płacić ZUSu i potem np. taki "PIT 2010" próbuje przy starcie zapisywać do 
C:\Windows i ignoruje CommandLine mimo, że rejestruje swoje rozszerzenie 
pliku.
yamma 

W dniu 2011-02-17 18:15, yamma pisze:
>> Kompletnie nie zgadzam się z tym zdaniem. Możesz powiedzieć w jaki
>> inny sposób można podchodzić do tworzenia algorytmów?
>
> Wiesz, mnie generalnie chodzi o to, że tworzone przez matematyków
> algorytmy wymuszają kompletnie niestrawne dla użytkownika interfejsy.
> Tak jak pisałem, często zamiast zwyczajnego "File->Open" uzytkownik musi
> rozwiązywać układ równań z 3 niewiadomymi. Zastanawiające jest to, że
> takie zachowania ja obserwuję najczęściej w naszych rodzimych produkcjach.
>
Ale co ma algorytm do interfejsu użytkownika? Czy dla Ciebie algorytm to 
zrobienie GUI? Jeśli tak to rozmawiamy o kompletnie innych sprawach...

>> Pytam zupełnie poważnie. Zawodowo zajmuję się tworzeniem algorytmów.
>> Jestem matematykiem. :) Co gorsze wielokrotnie pomagałem programistom
>> (nie matematykom) zrobić rozwiązanie, które działa wg założeń i do
>> tego wydajnie. Moje podejście jest dokładnie takie jak napisałeś.
>> Tworzę definicje i wzory. Nie mniej jednak chętnie bym poznał inne
>> podejścia, szczególnie, że mogłyby być lepsze.
>
> To zależy jak jesteś doświadczony. Wiele wzorców, metodologii nabywa się
Doświadczony w czym? W robieniu GUI mam zerowe doświadczenie. Ale jak 
powyżej napisałem. Dla mnie GUI to NIE są algorytmy. Algorytmy to np. 
problem komiwojażera.

> nie na studiach tylko po kilku latach pracy. Niestety, u nas polityka
Chętnie usłyszę co Ty byś polecał innego niż podejście matematyczne przy 
tworzeniu algorytmów (nie GUI :) )?

Pozdrawiam,
   Wit

Dnia 17-02-2011 o 18:36:58 Wit Jakuczun <wit.jakuczun_remove_@gmail.com>  
napisał(a):

> W dniu 2011-02-17 18:15, yamma pisze:
>>> Kompletnie nie zgadzam się z tym zdaniem. Możesz powiedzieć w jaki
>>> inny sposób można podchodzić do tworzenia algorytmów?
>>
>> Wiesz, mnie generalnie chodzi o to, że tworzone przez matematyków
>> algorytmy wymuszają kompletnie niestrawne dla użytkownika interfejsy.
>> Tak jak pisałem, często zamiast zwyczajnego "File->Open" uzytkownik musi
>> rozwiązywać układ równań z 3 niewiadomymi. Zastanawiające jest to, że
>> takie zachowania ja obserwuję najczęściej w naszych rodzimych  
>> produkcjach.
>>
> Ale co ma algorytm do interfejsu użytkownika? Czy dla Ciebie algorytm to  
> zrobienie GUI? Jeśli tak to rozmawiamy o kompletnie innych sprawach...
>
>>> Pytam zupełnie poważnie. Zawodowo zajmuję się tworzeniem algorytmów.
>>> Jestem matematykiem. :) Co gorsze wielokrotnie pomagałem programistom
>>> (nie matematykom) zrobić rozwiązanie, które działa wg założeń i do
>>> tego wydajnie. Moje podejście jest dokładnie takie jak napisałeś.
>>> Tworzę definicje i wzory. Nie mniej jednak chętnie bym poznał inne
>>> podejścia, szczególnie, że mogłyby być lepsze.
>>
>> To zależy jak jesteś doświadczony. Wiele wzorców, metodologii nabywa się
> Doświadczony w czym? W robieniu GUI mam zerowe doświadczenie. Ale jak  
> powyżej napisałem. Dla mnie GUI to NIE są algorytmy. Algorytmy to np.  
> problem komiwojażera.
>
>> nie na studiach tylko po kilku latach pracy. Niestety, u nas polityka
> Chętnie usłyszę co Ty byś polecał innego niż podejście matematyczne przy  
> tworzeniu algorytmów (nie GUI :) )?
>

Wydaje się, że piszesz specyficzne aplikacje.

Jak zastosujesz podejście matematyczne do aplikacji biznesowych?

-- 
3P

W dniu 2011-02-17 19:12, 3P pisze:
> Wydaje się, że piszesz specyficzne aplikacje.
>
> Jak zastosujesz podejście matematyczne do aplikacji biznesowych?

Rzucę z grubej rury: Sieci Petriego :-)

artur

W dniu 2011-02-17 19:12, 3P pisze:
>>> nie na studiach tylko po kilku latach pracy. Niestety, u nas polityka
>> Chętnie usłyszę co Ty byś polecał innego niż podejście matematyczne
>> przy tworzeniu algorytmów (nie GUI :) )?
>>
>
> Wydaje się, że piszesz specyficzne aplikacje.
>
> Jak zastosujesz podejście matematyczne do aplikacji biznesowych?
>
Wszystkie aplikacje, w tworzeniu których uczestniczyłem to były 
aplikacje biznesowe.

Pozdrawiam,
    Wit

Dnia 18-02-2011 o 08:21:50 Wit Jakuczun <wit.jakuczun_remove_@gmail.com>  
napisał(a):

> W dniu 2011-02-17 19:12, 3P pisze:
>>>> nie na studiach tylko po kilku latach pracy. Niestety, u nas polityka
>>> Chętnie usłyszę co Ty byś polecał innego niż podejście matematyczne
>>> przy tworzeniu algorytmów (nie GUI :) )?
>>>
>>
>> Wydaje się, że piszesz specyficzne aplikacje.
>>
>> Jak zastosujesz podejście matematyczne do aplikacji biznesowych?
>>
> Wszystkie aplikacje, w tworzeniu których uczestniczyłem to były  
> aplikacje biznesowe.
>
Rozpisz mi wzorami sklep internetowy :) Albo aplikację do sprzedaży  
ubezpieczeń.
Albo do likwidacji szkód.
-- 
3P

W dniu 2011-02-18 18:49, 3P pisze:
> Dnia 18-02-2011 o 08:21:50 Wit Jakuczun <wit.jakuczun_remove_@gmail.com>
> napisał(a):
>
>> W dniu 2011-02-17 19:12, 3P pisze:
>>>>> nie na studiach tylko po kilku latach pracy. Niestety, u nas polityka
>>>> Chętnie usłyszę co Ty byś polecał innego niż podejście matematyczne
>>>> przy tworzeniu algorytmów (nie GUI :) )?
>>>>
>>>
>>> Wydaje się, że piszesz specyficzne aplikacje.
>>>
>>> Jak zastosujesz podejście matematyczne do aplikacji biznesowych?
>>>
>> Wszystkie aplikacje, w tworzeniu których uczestniczyłem to były
>> aplikacje biznesowe.
>>
> Rozpisz mi wzorami sklep internetowy :) Albo aplikację do sprzedaży
> ubezpieczeń.
> Albo do likwidacji szkód.
A co ma sklep internetowy do tego o czym pisałem?

Pozdrawiam,
    Wit

Wit Jakuczun wrote:
> W dniu 2011-02-18 18:49, 3P pisze:
>> Dnia 18-02-2011 o 08:21:50 Wit Jakuczun
>> <wit.jakuczun_remove_@gmail.com> napisał(a):
>>
>>> W dniu 2011-02-17 19:12, 3P pisze:
>>>>>> nie na studiach tylko po kilku latach pracy. Niestety, u nas
>>>>>> polityka
>>>>> Chętnie usłyszę co Ty byś polecał innego niż podejście
>>>>> matematyczne przy tworzeniu algorytmów (nie GUI :) )?
>>>>>
>>>>
>>>> Wydaje się, że piszesz specyficzne aplikacje.
>>>>
>>>> Jak zastosujesz podejście matematyczne do aplikacji biznesowych?
>>>>
>>> Wszystkie aplikacje, w tworzeniu których uczestniczyłem to były
>>> aplikacje biznesowe.
>>>
>> Rozpisz mi wzorami sklep internetowy :) Albo aplikację do sprzedaży
>> ubezpieczeń.
>> Albo do likwidacji szkód.
> A co ma sklep internetowy do tego o czym pisałem?

Chyba za bardzo wziąłeś to do siebie. :-) Każdy user case mozna opisać 
matematycznymi wzorami i, niestety, są programiści-matematycy, którzy nie 
potrafią/nie chcą zrobić inaczej. Pół biedy, jeśli matematyka pozostaje na 
poziomie logiki biznesowej ale bardzo często taki sposób podejścia rzutuje 
na GUI. Dla przeciętnego początkującego programisty teoria relacyjnych baz 
danych stworzona przez Codda jest kompletnie niestrawna natomiast nie mają 
większego problemu z utworzeniem logicznego i poprawnego modelu danych. 
Preferują podejście intuicyjne a kompletnie odrzucają formalne.
Reasumując, takie czasami odnoszę wrażenie, że od kiedy programowanie 
przestało być elitarne i trafiło pod strzechy matematycy poczuli się 
strasznie pokrzywdzeni. Tak jakby ktoś im zabrał jedyną zabawkę. :-)
yamma 

Dnia 18-02-2011 o 22:56:50 Wit Jakuczun <wit.jakuczun_remove_@gmail.com>  
napisał(a):

> W dniu 2011-02-18 18:49, 3P pisze:
>> Dnia 18-02-2011 o 08:21:50 Wit Jakuczun <wit.jakuczun_remove_@gmail.com>
>> napisał(a):
>>
>>> W dniu 2011-02-17 19:12, 3P pisze:
>>>>>> nie na studiach tylko po kilku latach pracy. Niestety, u nas  
>>>>>> polityka
>>>>> Chętnie usłyszę co Ty byś polecał innego niż podejście matematyczne
>>>>> przy tworzeniu algorytmów (nie GUI :) )?
>>>>>
>>>>
>>>> Wydaje się, że piszesz specyficzne aplikacje.
>>>>
>>>> Jak zastosujesz podejście matematyczne do aplikacji biznesowych?
>>>>
>>> Wszystkie aplikacje, w tworzeniu których uczestniczyłem to były
>>> aplikacje biznesowe.
>>>
>> Rozpisz mi wzorami sklep internetowy :) Albo aplikację do sprzedaży
>> ubezpieczeń.
>> Albo do likwidacji szkód.
> A co ma sklep internetowy do tego o czym pisałem?
>
To aplikacja biznesowa.

Po prostu nie widziałem jeszcze podejścia matematycznego w programowaniu.
Napisz coś, podaj przykłady aplikacji.

P.S. Nie odbierz tego jako jakiś atak na siebie. Pytam z ciekawości.
-- 
3P

W dniu 2011-02-19 09:23, 3P pisze:
> Dnia 18-02-2011 o 22:56:50 Wit Jakuczun <wit.jakuczun_remove_@gmail.com>
> napisał(a):
>
>> W dniu 2011-02-18 18:49, 3P pisze:
>>> Dnia 18-02-2011 o 08:21:50 Wit Jakuczun <wit.jakuczun_remove_@gmail.com>
>>> napisał(a):
>>>
>>>> W dniu 2011-02-17 19:12, 3P pisze:
>>>>>>> nie na studiach tylko po kilku latach pracy. Niestety, u nas
>>>>>>> polityka
>>>>>> Chętnie usłyszę co Ty byś polecał innego niż podejście matematyczne
>>>>>> przy tworzeniu algorytmów (nie GUI :) )?
>>>>>>
>>>>>
>>>>> Wydaje się, że piszesz specyficzne aplikacje.
>>>>>
>>>>> Jak zastosujesz podejście matematyczne do aplikacji biznesowych?
>>>>>
>>>> Wszystkie aplikacje, w tworzeniu których uczestniczyłem to były
>>>> aplikacje biznesowe.
>>>>
>>> Rozpisz mi wzorami sklep internetowy :) Albo aplikację do sprzedaży
>>> ubezpieczeń.
>>> Albo do likwidacji szkód.
>> A co ma sklep internetowy do tego o czym pisałem?
>>
> To aplikacja biznesowa.
>
> Po prostu nie widziałem jeszcze podejścia matematycznego w programowaniu.
Nie w programowaniu, tylko w tworzeniu algorytmów.

Przytoczę jeszcze raz cytat kolegi yamma, który mnie zastanowił:
"Ja generalnie uważam, że tworzenie algorytmów wyłącznie przy pomocy 
matematycznych definicji i wzorów bardzo często prowadzi na manowce."

Moje doświadczenie mówi kompletnie co innego.

> Napisz coś, podaj przykłady aplikacji.
>
Aplikacja wspomagająca dział sprzedaży w firmie telekomunikacyjnej do 
tworzenia i obsługi ofert dla klientów biznesowych.
Aplikacja, która wspomaga instytucję w planowaniu przepływu towarów. 
Aplikacja wspomagająca planowanie tras dla pojazdów dostarczających 
towary z magazynu do klientów.
Aplikacja wspomagająca użytkownika w układaniu grafików czasu pracy dla 
pracowników.

Wszystkie te aplikacje zawierają w sobie moduły decyzyjne, które 
wymagają rozwiązywania trudnych obliczeniowo problemów (z klasy 
NP-trudnych). Ja nie znam innego sposobu jak podejście matematyczne 
(czyli wzory i definicje) aby te problemy rozwiązywać.

Pozdrawiam,
    Wit

W dniu 2011-02-19 09:04, yamma pisze:
>>> Rozpisz mi wzorami sklep internetowy :) Albo aplikację do sprzedaży
>>> ubezpieczeń.
>>> Albo do likwidacji szkód.
>> A co ma sklep internetowy do tego o czym pisałem?
>
> Chyba za bardzo wziąłeś to do siebie. :-) Każdy user case mozna opisać
Nie. Po prostu, jak napisałem 3P, mnie zainteresowało Twoje zdanie o 
podejściu matematycznym do tworzenia algorytmów:
"Ja generalnie uważam, że tworzenie algorytmów wyłącznie przy pomocy 
matematycznych definicji i wzorów bardzo często prowadzi na manowce."

Nie interesuje mnie podejście matematyczne do tworzenia sklepu 
internetowego. Mnie interesuje tworzenie algorytmów. Tym się zajmuję 
zawodowo i dlatego jestem ciekawy jakie inne podejścia są stosowane.
Jeśli byłbyś w stanie mi wyjaśnić swoje stanowisko to byłbym wdzięczny.

> logicznego i poprawnego modelu danych. Preferują podejście intuicyjne a
> kompletnie odrzucają formalne.
A na czym polega podejście intuicyjne?

Pozdrawiam,
   Wit

> Aplikacja wspomagająca dział sprzedaży w firmie telekomunikacyjnej do  
> tworzenia i obsługi ofert dla klientów biznesowych.
> Aplikacja, która wspomaga instytucję w planowaniu przepływu towarów.  
> Aplikacja wspomagająca planowanie tras dla pojazdów dostarczających  
> towary z magazynu do klientów.
> Aplikacja wspomagająca użytkownika w układaniu grafików czasu pracy dla  
> pracowników.
>
> Wszystkie te aplikacje zawierają w sobie moduły decyzyjne, które  
> wymagają rozwiązywania trudnych obliczeniowo problemów (z klasy  
> NP-trudnych). Ja nie znam innego sposobu jak podejście matematyczne  
> (czyli wzory i definicje) aby te problemy rozwiązywać.
>

No to się zgadzam. Pamiętam zajęcia z projektowania algorytmów. Nie  
lubiłem ich za bardzo :)


-- 
3P

Wit Jakuczun wrote:

> Nie. Po prostu, jak napisałem 3P, mnie zainteresowało Twoje zdanie o
> podejściu matematycznym do tworzenia algorytmów:
> "Ja generalnie uważam, że tworzenie algorytmów wyłącznie przy pomocy
> matematycznych definicji i wzorów bardzo często prowadzi na manowce."
>
> Nie interesuje mnie podejście matematyczne do tworzenia sklepu
> internetowego. Mnie interesuje tworzenie algorytmów. Tym się zajmuję
> zawodowo i dlatego jestem ciekawy jakie inne podejścia są stosowane.
> Jeśli byłbyś w stanie mi wyjaśnić swoje stanowisko to byłbym
> wdzięczny.

Podałem ci przykład obracających się kół. Drugi błąd jaki często robią 
programiści-matematycy, to przechowywanie danych finansowych w typach 
zmiennoprzecinkowych co w matematyce jest jak najbardziej naturalne, w 
programowaniu baz danych już niekoniecznie. W końcu, GUI opracowane przez 
matematyków często jest kompletnie niestrawne dla uzytkowników. Wyświetlanie 
GUI to też jest algorytm.

>> logicznego i poprawnego modelu danych. Preferują podejście
>> intuicyjne a kompletnie odrzucają formalne.
> A na czym polega podejście intuicyjne?

A to już sobie poczytaj. Nie będę za ciebie odrabiał lekcji. :-)
yamma 

W dniu 2011-02-19 20:36, yamma pisze:
>> Jeśli byłbyś w stanie mi wyjaśnić swoje stanowisko to byłbym
>> wdzięczny.
>
> Podałem ci przykład obracających się kół. Drugi błąd jaki często robią
> programiści-matematycy, to przechowywanie danych finansowych w typach
> zmiennoprzecinkowych co w matematyce jest jak najbardziej naturalne, w
> programowaniu baz danych już niekoniecznie. W końcu, GUI opracowane
> przez matematyków często jest kompletnie niestrawne dla uzytkowników.
Mnie NIE interesuje Twoje zdanie na temat tego jakimi programistami są 
matematycy. W ogóle matematycy mnie mało obchodzą w tej całej dyskusji.
A co do przykładów to są to jakieś szkolne błędy. I szkoda o nich 
dyskutować.

> Wyświetlanie GUI to też jest algorytm.
>
Formalnie masz rację ale ja nie o robieniu GUI mówiłem :).

>>> logicznego i poprawnego modelu danych. Preferują podejście
>>> intuicyjne a kompletnie odrzucają formalne.
>> A na czym polega podejście intuicyjne?
>
> A to już sobie poczytaj. Nie będę za ciebie odrabiał lekcji. :-)
Rozumiem i akceptuję, że nie potrafisz odpowiedzieć na proste pytanie. 
Nie ma problemu. Proponuję kończyć rozmowę.

Pozdrawiam,
   Wit

W dniu 2011-02-19 19:25, 3P pisze:
>> Wszystkie te aplikacje zawierają w sobie moduły decyzyjne, które
>> wymagają rozwiązywania trudnych obliczeniowo problemów (z klasy
>> NP-trudnych). Ja nie znam innego sposobu jak podejście matematyczne
>> (czyli wzory i definicje) aby te problemy rozwiązywać.
>>
> No to się zgadzam. Pamiętam zajęcia z projektowania algorytmów. Nie
> lubiłem ich za bardzo :)
>
No ok ale ja ciągle nie rozumiem o co chodzi z tym podejściem 
matematycznym.
Co jest z nim źle? :) Jednak widzę, że muszę zaakceptować to, że nie 
zaspokoję
mojej ciekawości w ramach tej dyskusji.
Ja na studiach takich zajęć nie miałem. Na matematyce takich rzeczy nie 
uczyli. Może dlatego nie mam obrzydzenia :).

Pozdrawiam,
   Wit

Dnia 19-02-2011 o 22:51:33 Wit Jakuczun <wit.jakuczun_remove_@gmail.com>  
napisał(a):

> W dniu 2011-02-19 19:25, 3P pisze:
>>> Wszystkie te aplikacje zawierają w sobie moduły decyzyjne, które
>>> wymagają rozwiązywania trudnych obliczeniowo problemów (z klasy
>>> NP-trudnych). Ja nie znam innego sposobu jak podejście matematyczne
>>> (czyli wzory i definicje) aby te problemy rozwiązywać.
>>>
>> No to się zgadzam. Pamiętam zajęcia z projektowania algorytmów. Nie
>> lubiłem ich za bardzo :)
>>
> No ok ale ja ciągle nie rozumiem o co chodzi z tym podejściem  
> matematycznym.
> Co jest z nim źle? :) Jednak widzę, że muszę zaakceptować to, że nie  
> zaspokoję
> mojej ciekawości w ramach tej dyskusji.
> Ja na studiach takich zajęć nie miałem. Na matematyce takich rzeczy nie  
> uczyli. Może dlatego nie mam obrzydzenia :).
>
Ja nie napisałem, że jest złe. Do takich problemów pewnie jest dobre.

-- 
3P

Wit Jakuczun wrote:
> W dniu 2011-02-19 20:36, yamma pisze:
>>> Jeśli byłbyś w stanie mi wyjaśnić swoje stanowisko to byłbym
>>> wdzięczny.
>>
>> Podałem ci przykład obracających się kół. Drugi błąd jaki często
>> robią programiści-matematycy, to przechowywanie danych finansowych w
>> typach zmiennoprzecinkowych co w matematyce jest jak najbardziej
>> naturalne, w programowaniu baz danych już niekoniecznie. W końcu,
>> GUI opracowane przez matematyków często jest kompletnie niestrawne
>> dla uzytkowników.
> Mnie NIE interesuje Twoje zdanie na temat tego jakimi programistami są
> matematycy. W ogóle matematycy mnie mało obchodzą w tej całej
> dyskusji. A co do przykładów to są to jakieś szkolne błędy. I szkoda
> o nich dyskutować.
>
>> Wyświetlanie GUI to też jest algorytm.
>>
> Formalnie masz rację ale ja nie o robieniu GUI mówiłem :).

A ja mówiłem przede wszystkim o GUI i pewnych nawykach wyniesionych z 
matematycznych uczelni. Nie mam pojęcia dlaczego zawęziłeś sobie moją 
wypowiedź do logiki biznesowej. Naprawdę, użytkownika niewiele interesuje co 
siedzi wewnątrz metody ObliczZdolnoscKredytowa pod warunkiem, że parametry 
tej metody są dla użytkownika do ogarnięcia.

>>> A na czym polega podejście intuicyjne?
>>
>> A to już sobie poczytaj. Nie będę za ciebie odrabiał lekcji. :-)
> Rozumiem i akceptuję, że nie potrafisz odpowiedzieć na proste pytanie.

Jaja sobie robisz? Przecież to podstawy teorii relacyjnej.
yamma 

W dniu 2011-02-20 09:44, yamma pisze:
>>>> A na czym polega podejście intuicyjne?
> Jaja sobie robisz? Przecież to podstawy teorii relacyjnej.
> yamma

???
Czyli uważasz, że istnieje jakaś teoria, której podstawą jest intuicja?
(naukowa a nie spiskowa)

Użytkownik "Wit Jakuczun" <wit.jakuczun_remove_@gmail.com> napisał w 
wiadomości news:ijjibo$el0$1@news.net.icm.edu.pl...

> Ponieważ piszesz, że do problemów można podchodzić od strony nie 
> matematycznej to mam pytanie: od jakiej strony należy podchodzić do 
> tworzenia algorytmów aby nie wleźć na manowce?

Wiedzieć, że komputer nie jest po to aby liczyć, tylko aby szybko rozwiązać 
problem.

Matematyk będzie liczył sinusy, programista zrobi tablicę z wyliczonymi 
wartościami,
matematyk policzy pi ze stosunku obwodu koła do jego średnicy, programista 
zdefiniuje stałą, programista zrobi przesunięcie bitowe, matematyk będzie 
dzielnie dzielił przez 4, programiasta zrobi ergonomiczne GUI, matematyk 
naszpikuje je dziesiątkami odczytów różnych dziwnych wartości, które 
zrozumie tylko drugi matematyk. Zresztą miałem okazję na informatyce mieć 
przedmiot algorytmy, na którym wykłady prowadził programista, a ćwiczenia 
matematyk. To co dla programisty było tablicą, dla matematyka stawało się 
macierzą, czy wektorami. Przy okazji najprostszego algorytmu np. typu dziel 
i zwyciężaj, wykład z analizy matematycznej mu się robił. Matematycy są 
bardzo potrzebni, ale to są ludzie którzy nawet obiad najchętniej zamienili 
by ci na opis wektorowy, a następnie zapytali jak smakowało... 

W dniu 2011-02-21 20:11, Marcin Wasilewski pisze:
> Użytkownik "Wit Jakuczun" <wit.jakuczun_remove_@gmail.com> napisał w
> wiadomości news:ijjibo$el0$1@news.net.icm.edu.pl...
>
>> Ponieważ piszesz, że do problemów można podchodzić od strony nie
>> matematycznej to mam pytanie: od jakiej strony należy podchodzić do
>> tworzenia algorytmów aby nie wleźć na manowce?
>
> Wiedzieć, że komputer nie jest po to aby liczyć, tylko aby szybko
> rozwiązać problem.
>
Zgoda. Czasami komputer w ogóle nie jest potrzebny aby rozwiązać problem.

> Matematyk będzie liczył sinusy, programista zrobi tablicę z wyliczonymi
> wartościami,
> matematyk policzy pi ze stosunku obwodu koła do jego średnicy,
> programista zdefiniuje stałą, programista zrobi przesunięcie bitowe,
> matematyk będzie dzielnie dzielił przez 4, programiasta zrobi
> ergonomiczne GUI, matematyk naszpikuje je dziesiątkami odczytów różnych
> dziwnych wartości, które zrozumie tylko drugi matematyk. Zresztą miałem
> okazję na informatyce mieć przedmiot algorytmy, na którym wykłady
> prowadził programista, a ćwiczenia matematyk. To co dla programisty było
> tablicą, dla matematyka stawało się macierzą, czy wektorami. Przy okazji
> najprostszego algorytmu np. typu dziel i zwyciężaj, wykład z analizy
> matematycznej mu się robił. Matematycy są bardzo potrzebni, ale to są
> ludzie którzy nawet obiad najchętniej zamienili by ci na opis wektorowy,
> a następnie zapytali jak smakowało...
To jest zestaw ogólników o matematykach. Moim zdaniem w większości 
nieprawdziwych ale to jest mało istotne gdyż mnie jak już wcześniej 
napisałem matematycy mało mnie interesują. Nie o to pytałem. Ale dzięki 
za wysiłek. :)

Pozdrawiam,
   Wit

W dniu 2011-02-20 09:44, yamma pisze:
>>> Wyświetlanie GUI to też jest algorytm.
>>>
>> Formalnie masz rację ale ja nie o robieniu GUI mówiłem :).
>
> A ja mówiłem przede wszystkim o GUI i pewnych nawykach wyniesionych z
> matematycznych uczelni. Nie mam pojęcia dlaczego zawęziłeś sobie moją
> wypowiedź do logiki biznesowej. Naprawdę, użytkownika niewiele
Cytat z Ciebie:"Ja generalnie uważam, że tworzenie algorytmów wyłącznie 
przy pomocy matematycznych definicji i wzorów bardzo często prowadzi na 
manowce." W tym zdaniu nie ma słowa o GUI. Jest za to dużo o 
algorytmach. Rozumiem, że chodziło Ci jedynie o algorytmy, którzy 
przykłady podawałeś (np. obracające się kółko). Mi nie o takie algorytmy 
chodziło i myślę, że dlatego nie mogę zrozumieć co do mnie piszesz.

> interesuje co siedzi wewnątrz metody ObliczZdolnoscKredytowa pod
> warunkiem, że parametry tej metody są dla użytkownika do ogarnięcia.
>
Od tego co jest w środku zależy jakie trzeba wystawić parametry na 
zewnątrz. Od tego co jest w środku zależy na ile ta funkcja będzie 
zwracała SENSOWNE wyniki. Niektórych rzeczy nie da się zrobić chwytami 
typu "obracające się kółko zrobione w Paint'cie". Akurat przykład, który 
podałeś WYMAGA użycia wzorów.

>>>> A na czym polega podejście intuicyjne?
>>>
>>> A to już sobie poczytaj. Nie będę za ciebie odrabiał lekcji. :-)
>> Rozumiem i akceptuję, że nie potrafisz odpowiedzieć na proste pytanie.
>
> Jaja sobie robisz? Przecież to podstawy teorii relacyjnej.
Nie robię sobie jaj. Po prostu mi nie odpowiedziałeś na pytanie, które 
brzmiało "A na czym polega podejście intuicyjne?".

Myślę, że rozmowa jest już bardzo OT, tak więc z mojej strony kończę.

Pozdrawiam,
   Wit

On Thu, 17 Feb 2011 09:47:42 +0100, "Wiktor Zychla"
<wzychla@nospam.com> wrote:

>absolutnie bowiem zgadzam sie z tym co piszesz powyzej jako z pewna regula 
>OGÓLNA. moje pytanie dotyczylo konkretnego przypadku, tych Twoich nazwanych 
>par z nazwanymi polami, a nie podwazania sensu istnienia "koncepcji wyzszego 
>rzedu" w ogólnosci. moze po prostu nie wyczulem, ze nie chodzi Ci konkretnie 
>o te pary, tylko o mechanizm ogólny, stad to pytanie.

Oki.

>to na co zwracam Twoja uwage, to to, ze nie dostrzegasz mozliwosci uzyskania 
>takiego samego efektu INNYMI srodkami. bardzo przywiazales sie do tego, ze 
>masz te makra "w jezyku". a czymze innym jest mechanizm szablonów generatora 
>kodu? szablony dokladnie tworzy sie w TYM samym jezyku programowania, 

Nie do konca sie z tym zgodze -- dlatego, ze w ten sposob oslabia sie
jezyk.

Chodzi o to, ze jesli to bylaby jedyna, absolutnie jedyna rzecz, ktora
trzeba obejsc... OK. Niech bedzie.

Ale tak nie jest -- w C# nie ma wielu rzeczy (zabawne, ale niektora sa
w innych jezykach rodziny .net -- np. sygnowanie funkcji
rekurencyjnych w F#, czy mozliwosc przekazywania properties via ref w
VB) i wiele z nich jest utrzymywane w stanie nicosci, bo mozna je
latwo obejsc (podejscie Erica Lipperta).

Ale jednak ma to znaczenie -- nameof, ktory jest zrobiony naokolo jest
duzo wolniejszy od swojego nieistniejacego analoga z jezyk, dluzsza
skladnia wydluza czytanie.

Oczywiscie trudno sie odniesc do czegos czego nie ma, ale uczciwie
rozmawiajac mozna zrobic porownanie do jezykow, ktore nie maja pewnych
cech C# i w ktorych tez da sie do obejsc. Np. skladnia lamdb w C#
uwazam za maksymalnie elegancka, czyta sie ja fenomenalnie.

Porownaj to np. do chociazby D. Baaardzo bliska skladnia, ale jednak
juz rozwodniona. Pojdz dalej i wez na tapete PHP -- jeszcze dluzsza
skladnia.

W pewnym momencie wiecej konstrukcji tworzysz dla rozwiazania
technicznego, niz dla merytorycznego wyrazenia mysli.


>szablon ma czesc deklaratywna, która ewaluuje sie "jak jest" i czesc 
>imperatywna, napisana w C#/VB czy czymtam chcesz, która wykonuje sie podczas 
>generowania. mozesz miec swój szablon DefTuple i w jednym miejscu napisane 
>ile razy chcesz go wywolac. a to, ze pliki z tymi definicjami nie beda mialy 
>rozszerzenia *.cs i nie bedzie ich przetwarzal kompilator? czy to tak 
>naprawde ma znaczenie?

W dluzszej perspektywie wg mnie ma. 

Na wszelki wypadek -- pewnie znasz:

Jezyk ma znaczenie (sila ekspresji):
http://www.joelonsoftware.com/items/2006/08/01.html

Grosz do grosza (1000 papercuts):
http://www.joelonsoftware.com/items/2007/09/11.html

milego dnia, hej
-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On Sat, 19 Feb 2011 20:36:47 +0100, "yamma" <yamma@wp.pl> wrote:

>Wit Jakuczun wrote:
>
>> Nie. Po prostu, jak napisałem 3P, mnie zainteresowało Twoje zdanie o
>> podejściu matematycznym do tworzenia algorytmów:
>> "Ja generalnie uważam, że tworzenie algorytmów wyłącznie przy pomocy
>> matematycznych definicji i wzorów bardzo często prowadzi na manowce."
>>
>> Nie interesuje mnie podejście matematyczne do tworzenia sklepu
>> internetowego. Mnie interesuje tworzenie algorytmów. Tym się zajmuję
>> zawodowo i dlatego jestem ciekawy jakie inne podejścia są stosowane.
>> Jeśli byłbyś w stanie mi wyjaśnić swoje stanowisko to byłbym
>> wdzięczny.
>
>Podałem ci przykład obracających się kół. Drugi błąd jaki często robią 
>programiści-matematycy, to przechowywanie danych finansowych w typach 
>zmiennoprzecinkowych co w matematyce jest jak najbardziej naturalne, w 
>programowaniu baz danych już niekoniecznie. W końcu,

Neistety, programisci robia podstawowe bledy przy operowaniu na
liczbach reprezentujacych srodki platnicze. Problemem jest bowiem
zaokraglanei wynikow, i ten proces jest tregulowany odpowiednimi
dokumentami i to na poziomie UE. Pzrecietny programista nei ma o tym
zielonego pojacia. A za program finansowy ktory robi zle zaokraglenia
mozna zwyczajnie pojsc siedziec.

A.L.

On Mon, 21 Feb 2011 20:11:52 +0100, "Marcin Wasilewski"
<jakis@adres.pl> wrote:

>Użytkownik "Wit Jakuczun" <wit.jakuczun_remove_@gmail.com> napisał w 
>wiadomości news:ijjibo$el0$1@news.net.icm.edu.pl...
>
>> Ponieważ piszesz, że do problemów można podchodzić od strony nie 
>> matematycznej to mam pytanie: od jakiej strony należy podchodzić do 
>> tworzenia algorytmów aby nie wleźć na manowce?
>
>Wiedzieć, że komputer nie jest po to aby liczyć, tylko aby szybko rozwiązać 
>problem.
>
>Matematyk będzie liczył sinusy, programista zrobi tablicę z wyliczonymi 
>wartościami,

U mnei w pracy "mlody programistyczny miszcz bez matematyki"
przejechal sie na takim problemie:

Produkt scharakteryzowany jest przez 500 binarnych atrybutow.
Produktow jest 10 tysiecy roznych  rodzajow. Kazdy ma inny wektor
atrybutow

Przychodzi klient i pyta: Macie produkt ktory ma A i B lub C albo A i
D i E albo A i D lub E? Takie pytanie moze byc dosuc dlugie i
skomplikowane

Jak Kolega rozwiazalby ten problem "programistycznie"?...

A.L.

Użytkownik "A.L." <lewando@aol.com> napisał w wiadomości 
news:5jofm6hkorbit4mqf6epp4n5218e6glt2t@4ax.com...

> U mnei w pracy "mlody programistyczny miszcz bez matematyki"
> przejechal sie na takim problemie:
> Produkt scharakteryzowany jest przez 500 binarnych atrybutow.
> Produktow jest 10 tysiecy roznych  rodzajow. Kazdy ma inny wektor
> atrybutow
> Przychodzi klient i pyta: Macie produkt ktory ma A i B lub C albo A i
> D i E albo A i D lub E? Takie pytanie moze byc dosuc dlugie i
> skomplikowane
> Jak Kolega rozwiazalby ten problem "programistycznie"?...

    Za pomocą sekwentów Gentzena?