Jakie języki dla przyszłego programisty???

Tworzenie hacków na jakieś procesory/ systemy/ programy wynika z monopolu na implementację i z rzadkich aktualizacji. Na taką np Javę nie robi się hacków bo jest n różnych implementacji JVMa, a nawet Sunowska Java ma co chwilę kolejne Update'y niektóre usuwające bugi powodujące niekompatybilność.

ZTCW: Oprócz Windowsa hacki dotknęły np procesorów Intela, czyli sławetny Unreal Model w przeróżnych BIOSach wykorzystujący bugi w implementacjach x86 u Intela. Kolejne procesory musiały implementować tego samego buga, aby poprzednie BIOSy mogły na nich działać.

jednak wolałbym zająć się aplikacjami i programami
więc podsumowując języki które muszę wykuć to C, C++ i C#, póki co.
przeglądałem ostatnio ofert pracy i było mnóstwo tych języków C.
Mam do studiów 1,5 roku więc jakby udało się je opanować dosyć dobrze było by super :)
co do dalszych będę zastanawiał się później :)

przemo1722 napisał(a)

przeglądałem ostatnio ofert pracy i było mnóstwo tych języków C.

Hue hue

przemo1722 napisał(a)

Mam do studiów 1,5 roku więc jakby udało się je opanować dosyć dobrze było by super :)

Ktoś mądrzejszy ode mnie na tym forum napisał żeby nie mylić znajomości języka z umiejętnością programowania. W półtorej roku pewnie dasz radę nauczyć się trzech języków, ale programować zapewne nie będziesz umiał w żadnym. Ale nie zniechęcaj się, nie znam Cię i może jesteś na tyle pracowity że to co napisałem Ciebie nie dotyczy ;)

(edit literówki)

aurel napisał(a)

Z tych względów pytania me do kolegów z pracy są bardzo rzadkie, prędzej topik na forum zakładam.

Tracicie na synergii. Lepiej jest mieć kogo spytać, bo często jest tak, że ktoś coś już zna, więc rozwiąże problem szybciej niż Twoje kombinowanie. Praca zespołowa to dobra rzecz.

donkey7 napisał(a)

To tylko kwestia czasu jak typowe projekty staną się na tyle skomplikowane, że pisanie ich w obecnym C# czy Javie przestanie być opłacalne i lepiej będzie zatrudnić bardziej sprytnych programistów Scali, aby zrobili projekt kilka razy bardziej stabilny kilka razy mniejszym nakładem pracy.

Myślę, że projekty już teraz, a nawet dużo wcześniej były skomplikowane. Ale tego problemu nie naprawi żaden język sam z siebie, bo w każdym można pisać brzydki, nieczytelny, nieutrzymywalny, a nawet sprzeczny z paradygmatem kod. Problemem dla utrzymania czy wydajności oprogramowania jest architektura, nie język sam z siebie.
Oczywiście pewne języki są zwięźlejsze i czytelniejsze od innych, ale to samo z siebie nic nie daje. Trzeba jeszcze mieć grupę specjalistów danego języka, żeby móc rozpocząć projekt w nim, oraz musi to być język na tyle popularny, żeby w razie czego bez problemu znalazło się kolejnych specjalistów.
Języka można generalnie poznać na dwa sposoby - albo na uczelni albo samemu. Na uczelniach dominują języki imperatywne, a gdy ktoś sam zaczyna się uczyć, to zazwyczaj pyta starszych kolegów, którzy doradzają mu C++ albo Delphi. Więc skąd brać tych specjalistów?
Może faktycznie kiedyś będzie tak jak mówisz, ale to chyba wymaga zmiany pokoleniowej. :)

somekind napisał(a)

donkey7 napisał(a)

To tylko kwestia czasu jak typowe projekty staną się na tyle skomplikowane, że pisanie ich w obecnym C# czy Javie przestanie być opłacalne i lepiej będzie zatrudnić bardziej sprytnych programistów Scali, aby zrobili projekt kilka razy bardziej stabilny kilka razy mniejszym nakładem pracy.

:O

several napisał(a)

Ktoś mądrzejszy ode mnie na tym forum napisał żeby nie mylić znajomości języka z umiejętnością programowania.

To chyba najczęściej ja tak narzekam na początkujących. Pytania typu 'czy jak się nauczę C++ to będę superprogramistą' padają regularnie. Programowanie to proces twórczy, język to tylko narzędzie. Z moich obserwacji wynika, że większość ludzi nie pracuje z językiem, od którego zaczynali (ja zresztą też nie).

przemo1722 napisał(a)

jednak wolałbym zająć się aplikacjami i programami

Aplikacje to programy... Fajnie by było gdybyś wiedział jakie programy chcesz faktycznie tworzyć, od tego zależy późniejszy wybór języków. Potrzebujesz czegoś, co działa niezawodnie całymi miesiącami bez restartu, z możliwością aktualizacji podczas pracy? To tutaj raczej języki pod kontrolą VM tylko w grę wchodzą, ze szczególnym uwzględnieniem tak dziwnego tworu jak Common Lisp. Może jednak coś bardzo mocno wpasowującego się w system operacyjny? C albo i assembler, zależnie od stopnia ingerencji.

przemo1722 napisał(a)

języki które muszę wykuć to C, C++ i C#, póki co.

Każdy z nich ma swój standard ISO, chcesz powiedzieć, że wkujesz te wszystkie ISO? Powodzenia ze standardem C++ ;] Poważniej mówiąc - nie wkujesz, języków się nie wkuwa. Jeżeli już to powinieneś zrozumieć filozofię i mechanikę języka, nauczyć się nim posługiwać, wykorzystywać mocne strony i unikać słabe. Nie ma miejsca na bezmyślne zapamiętywanie regułek. Nikt nie mówi, że musisz opanować akurat C(++) lub C#.

Na dobrą sprawę to powinieneś opanować C (lub coś innego pracującego na średnim poziomie, ale alternatywy za bardzo nie ma), potem jakiś język skryptowy, np. Pythona (ew. Ruby, byle nie Perla). Sporo softu można nim automatyzować (chociażby Interactive Disassembler...), może pracować w zastępstwie skryptów powłoki, jest przenośny, nie wymaga kompilacji itd. Generalnie zapewnia to, co język skryptowy zapewniać powinien - szybkość i łatwość tworzenia prostych narzędzi, przy tym elastyczność i spore możliwości.

przemo1722 napisał(a)

przeglądałem ostatnio ofert pracy i było mnóstwo tych języków C.

Nie wiem czy ktoś Cię już uświadomił, ale C# z C(++) ma wspólne jedynie 'C' w nazwie, klamerki w kodzie, ew. kilka nazw typów, których podobieństwo nie zawsze sprowadza się do czegoś więcej niż sama nazwa.

przemo1722 napisał(a)

Mam do studiów 1,5 roku więc jakby udało się je opanować dosyć dobrze było by super :)
co do dalszych będę zastanawiał się później :)

Zamiast skupiać się na językach powinieneś raczej położyć nacisk na znajomość różnych paradygmatów (przynajmniej na razie) i programowania jako takiego. Chcesz zacząć od języków w sumie typowo imperatywnych, wypadałoby się do tego nie ograniczać. Polecam coś funkcyjnego, jeżeli nie boisz się podejścia 'akademickiego' to nawet czysto funkcyjnego, Haskell. Z rzeczy bardziej przyjaznych programistom to Scala, mająca na tym forum małe kółko fanatycznych wyznawców. Język łączący programowanie obiektowe z funkcyjnym, oferujący bardzo wysoką abstrakcję i cholerną wręcz swobodę. Oczywiście wspomniane Python czy Ruby, nawet miejscami C#, oferuje wsparcie dla programowania funkcyjnego, jednak kładzie zbyt mały nacisk żeby faktycznie naturalnie umożliwiał opanowanie tego paradygmatu.

A może coś potencjalnie całkowicie bezużytecznego zawodowo i 'studyjnie'? Coś, co da faktyczne pojęcie o programowaniu? Scheme i przerobienie Structure and Interpretation of Computer Programs to ciekawa alternatywa na start. Chyba lepszej książki na początek nie spotkałem.

Nastawianie się na to, co może być na studiach albo przydać się w pracy nie ma sensu na tym etapie rozwoju.

najlepiej gdyby któs stworzył jakiś nowoczesny kompilowany wieloparadygmatowy język i do tego visual studio ;f
do tego z ładną składnią
marzenia ściętej głowy ;/
takiego następce c/c++

szkoda ze spaprano sprawe z D

C# jest kompilowany, jest nowoczesny, wieloparadygmatowy i głównie dla niego powstają Visuale od kilku wersji... A D? D jest miejscami do 'd...' nie podobny.

kompilowany od razu do kodu maszynowego a nie pośredniego
mój bład mogłem napisać
albo sie gdzieś myle bo aż takim znawcą nie jestem jeszcze* xD

Kompilacja od razu do kodu maszynowego to nie zaleta tylko wada języka programowania (o ile możemy mówić o tym w kontekście języka, nie samej implementacji). Do tego trzeba doliczyć cuda typu pointery itd. w tych całych C(++) czy D, kolejne badziewie, które poza absolutnie najniższym poziomem systemu operacyjnego jest zwyczajnie zbędne.

C# w porównaniu do Scali jest mniej elastyczny, mniej zwięzły i po prostu brzydszy :) A i sama Scala ideałem nie jest (wg mnie).

deus napisał(a)

Kompilacja od razu do kodu maszynowego to nie zaleta tylko wada języka programowania (o ile możemy mówić o tym w kontekście języka, nie samej implementacji)
Właśnie: mimo że jakoś nikomu się nie spieszy do stworzenia natywnego kompilatora C#, nie ma po temu wielkich przeszkód: niektóre rzeczy uległyby uproszczeniu i zredukowaniu do niczego (marshalling), z pewnymi byłby problem (refleksja). Ale co by to dało? czy kod działałby wyraźnie szybciej? Nie.

Do tego trzeba doliczyć cuda typu pointery itd. w tych całych C(++) czy D, kolejne badziewie, które poza absolutnie najniższym poziomem systemu operacyjnego jest zwyczajnie zbędne.
Zależy w jakim języku: C jest tak skonstruowane, że wskaźniki zbędne nie są ;-)

somekind napisał(a)

donkey7 napisał(a)

To tylko kwestia czasu jak typowe projekty staną się na tyle skomplikowane, że pisanie ich w obecnym C# czy Javie przestanie być opłacalne i lepiej będzie zatrudnić bardziej sprytnych programistów Scali, aby zrobili projekt kilka razy bardziej stabilny kilka razy mniejszym nakładem pracy.

Myślę, że projekty już teraz, a nawet dużo wcześniej były skomplikowane. Ale tego problemu nie naprawi żaden język sam z siebie, bo w każdym można pisać brzydki, nieczytelny, nieutrzymywalny, a nawet sprzeczny z paradygmatem kod. Problemem dla utrzymania czy wydajności oprogramowania jest architektura, nie język sam z siebie.
Oczywiście pewne języki są zwięźlejsze i czytelniejsze od innych, ale to samo z siebie nic nie daje. Trzeba jeszcze mieć grupę specjalistów danego języka, żeby móc rozpocząć projekt w nim, oraz musi to być język na tyle popularny, żeby w razie czego bez problemu znalazło się kolejnych specjalistów.
Języka można generalnie poznać na dwa sposoby - albo na uczelni albo samemu. Na uczelniach dominują języki imperatywne, a gdy ktoś sam zaczyna się uczyć, to zazwyczaj pyta starszych kolegów, którzy doradzają mu C++ albo Delphi. Więc skąd brać tych specjalistów?
Może faktycznie kiedyś będzie tak jak mówisz, ale to chyba wymaga zmiany pokoleniowej. :)

Oj trzeba poczekać, ale myślę, że lepiej się dostosowywać już za młodu, żeby potem nie być dinozaurem takim jakimi są dzisiaj programiści np COBOLa czy podobnych.

Właśnie: mimo że jakoś nikomu się nie spieszy do stworzenia natywnego kompilatora C#, nie ma po temu wielkich przeszkód: niektóre rzeczy uległyby uproszczeniu i zredukowaniu do niczego (marshalling), z pewnymi byłby problem (refleksja). Ale co by to dało? czy kod działałby wyraźnie szybciej? Nie.

Ale C# przecież ma AOT ZTCW.

donkey7 napisał(a)

Oj trzeba poczekać, ale myślę, że lepiej się dostosowywać już za młodu, żeby potem nie być dinozaurem takim jakimi są dzisiaj programiści np COBOLa czy podobnych.

Albo nie dostosowywać się, żeby nie być dziwolągiem samotnie programującym w nowoczesnym języku. ;P
C++ jakoś ciągle się trzyma, a jest niespójny, mało zwięzły i zwyczajnie brzydki. Nie tak łatwo wytępić ludzkie przyzwyczajenia.

Azarien napisał(a)

Właśnie: mimo że jakoś nikomu się nie spieszy do stworzenia natywnego kompilatora C#

Słyszałeś o Bartok'u?

Czemu sadzisz ze c++ to jezyk brzydki? I co rozumiesz przez okreslenie "niespojny".
Nie zgodzilbym tez sie ze nie jest zwiezly bo w porownaniu z wieloma algorytmami w c++ i alternatywnie w innych jezykach to c++ jest bardzo zwiezly i co lepsze jest przejrzysty. Ale ok ta zwiezlosc to jest najmniejszy akurat problem.
Ale czemu brzydki??? czemu niespojny?
c++ jest jezykiem w ktorym kod moze byc zarowno brzydki / paskudny jak i piekny i cudowny. Zalezy to od programisty i jego "pilnowania sie". c++ nie narzuca programiscie stylu to on sobie styl wybiera i to jest zajebiste.

Nie zgodzilbym tez sie ze nie jest zwiezly bo w porownaniu z wieloma algorytmami w c++ i alternatywnie w innych jezykach to c++ jest bardzo zwiezly i co lepsze jest przejrzysty.

Np. taki kod:

while(*a++=*b++);

Jest brzydki i niespójny. Co np. wg ciebie oznacza zapis std::vector& pierd();? Jak chcesz piękny język kompilowany do binarki to masz D, gdzie jest wszystko ładnie i pięknie poza szablonami, ale da się zrobić w taki sposób by nie były takie złe.

No tak teraz rozumiem co mozna bylo miec na mysli. Ale to sa raczej rzadkie przypadki. I jest to slabo czytelne dla kogos z zewnatrz natomiast dla programisty ktory w tym siedzi i to pisal jest to jak najbardziej czytelne. Wie jak to dziala etc.
No ale ok rozumiem teraz o co chodzilo.

somekind napisał(a)

donkey7 napisał(a)

Oj trzeba poczekać, ale myślę, że lepiej się dostosowywać już za młodu, żeby potem nie być dinozaurem takim jakimi są dzisiaj programiści np COBOLa czy podobnych.

Albo nie dostosowywać się, żeby nie być dziwolągiem samotnie programującym w nowoczesnym języku. ;P

Samotnie? Scala już jest jednym z kilku najbardziej liczących się języków na JVMa. Za jakieś 2 lata spokojnie może być drugim językiem po Javie - język rozwija się bardzo szybko - szybkość pisania kodu jest mniej więcej na równi z językami skryptowymi, a do JVMa wprowadzane są w końcu jakieś optymalizacje typu Escape Analysis, bardziej zaawansowana dewirtualizacja itd dzięki którym kod funkcyjny zbliża się wydajnością do błędogennych i nieczytelnych zagnieżdżanych pętli.

polaczek:
Krotki: http://www.boost.org/doc/libs/1_45_0/libs/tuple/doc/tuple_users_guide.html
Lambdy: http://www.boost.org/doc/libs/1_45_0/doc/html/lambda/le_in_details.html

Krotki są np po to, żeby nie było pytań typu "jak zwrócić więcej niż jedną wartość z funkcji nie robiąc dodatkowej klasy i nie robiąc za każdym razem dodatkowych zmiennych?". Lamby są np po to, aby nie musieć przekazywać mnóstwa parametrów do funkcji za każdym razem, parametry z zewnętrznego obiektu są bindowane do domknięcia przy jego tworzeniu - czyli w jednym tylko miejscu w kodzie.

Porównaj sobie te z C++ do tych ze Scali czy chociażby z C#.

polaczek17 napisał(a)

Czemu sadzisz ze c++ to jezyk brzydki? I co rozumiesz przez okreslenie "niespojny".

Niespójny to ma system typów, składnię tragiczną, szczególnie w C++0x. A właśnie, jeszcze mają szansę wyjść z twarzą z rozwoju tego 'standardu', jak się pospieszą to może wyjdzie C++0F... Może zacznę od tego, że kolejność ewaluacji jest nieokreślona, kolejność inicjalizacji globalnych obiektów również, trzeba robić paskudne hacki albo korzystać z odpowiednich dekoratorów (w GCC), które i tak tylko minimalnie poprawiają sytuację. Sprawdzałeś kiedyś stan strumienia C++? Pewnie robiłeś to tak: if (stream). Wiesz co tutaj się dzieje? Zachodzi niejawna konwersja do void *, który znowu jest wartościowany do wartości logicznej. Taki trochę trick na radzenie sobie z mechaniką języka i unikanie pewnych rodzajów błędów. Do pointera możesz przypisać tylko jedną wartość liczbową bez rzutowania, zero, co jest znowu hackiem na spierdolony system typów. Zadanie dla Ciebie, jakie będą efekty i czym się różnią poniższe konstrukcje:

/* 1 */ { const int x = 666; /**/ { int x = x; } }
/* 2 */ { const int x = 666; /**/ { int x(x);  } }
/* 3 */ { const int x = 666; enum {     x = x  };}

polaczek17 napisał(a)

Nie zgodzilbym tez sie ze nie jest zwiezly bo w porownaniu z wieloma algorytmami w c++ i alternatywnie w innych jezykach to c++ jest bardzo zwiezly i co lepsze jest przejrzysty.

Aha, kod korzystający z efektów ubocznych i różnych hacków z konwersjami i przypisaniami, jak pokazano. Ten kod nie jest ani czytelny ani 'ładny'.

polaczek17 napisał(a)

c++ jest jezykiem w ktorym kod moze byc zarowno brzydki / paskudny jak i piekny i cudowny. Zalezy to od programisty i jego "pilnowania sie". c++ nie narzuca programiscie stylu to on sobie styl wybiera i to jest zajebiste.

Może i zajebiste, ale autorom niektórych programów powinno się pourywać rączki żeby z tej zajebistości nie korzystali... Zgadnij jaki program mam na myśli.

Zadanie dla Ciebie, jakie będą efekty i czym się różnią poniższe konstrukcje:

/* 1 */ { const int x = 666; /**/ { int x = x; } }
/* 2 */ { const int x = 666; /**/ { int x(x);  } }
/* 3 */ { const int x = 666; enum {     x = x  };}

Ani jednego z tych kodow nie przyjmie kompilator ze wzgledu na duplikacje nazw.

Aha, kod korzystający z efektów ubocznych i różnych hacków z konwersjami i przypisaniami, jak pokazano. Ten kod nie jest ani czytelny ani 'ładny'.

No coz czym wiec wyjasnic taka popularnosc jezyka c++?

Może i zajebiste, ale autorom niektórych programów powinno się pourywać rączki żeby z tej zajebistości nie korzystali... Zgadnij jaki program mam na myśli.

Heh, no niestety w pojedynke nie latwo zbudowac tak duzy program i go utrzymac. Ale z kazda proba jest lepiej. Porownaj sobie poprzednia wersje z aktualna. I pomysl jaka moze byc nastepna :)

polaczek17 napisał(a)

Ani jednego z tych kodow nie przyjmie kompilator ze wzgledu na duplikacje nazw.

Tak, tak... chyba Ciebie kompilator nie przyjmie. Idź do Newbie i nie wracaj.

polaczek17 napisał(a)

No coz czym wiec wyjasnic taka popularnosc jezyka c++?

Proste - m.in. Windows. To jedyny obok C język natywny wspierany przez twórców najpopularniejszego systemu operacyjnego. Poza tym także Unix jest w C więc pochodne C siłą rzeczy muszą być popularne, prawda? Po prostu nie było dla C++ alternatywy.

1 - brak inicjalizacji tego { const int x = 666; { int x = x; } } iksa ?
2 - 666
3 - 666

Wygrałem quiz ? Starczyło to wklepać, co do 2 i 3 tak myślałem, jednak nie wiem dlaczego w 1 tak to przyjmuje ?

@polaczek17

Opracowałeś nowy algorytm generowania nazw kontrolek ;p ?

Popsułeś zabawę. O tyle śmieszne, że i ja popsułem zabawę, trzecia forma nie powinna się skompilować zgodnie z zasadami C++ (jeżeli jakiś kompilator Ci to skompilował to znaczy, że jest do d**y) bo zapomniałem dodać klamerki dla nowego scope.

To działa tak, że C++ w praktycznie każdej formie definicji stosuje inne reguły:

1. w deklaracji nazwa zmiennej jest widoczna natychmiast, także przy inicjalizacji masz ją od razu widoczną po =, typowy do bólu błędny self-asignment; zmienna przyjmie wartość nieokreśloną, tj. zostaną jej przypisane śmieci, które w jej miejscu leżały w pamięci;
2. masz wywołanie konstruktora, co de facto jest inicjalizacją, ale jest 'przyklejane' do deklaracji, tj. tworzona zmienna jest widoczna dopiero za nawiasami konstruktora; używa x z zewnętrznego scope;
3. tworzysz enum, wartość enuma staje się widoczna dopiero po zakończeniu inicjalizacji, lub jej pominięciu (wartość domyślna); po ujęciu enuma w dodatkową parę klamerek (nie chcę tamtego kodu poprawiać) otrzymasz wartość jak w poprzednim przykładzie, z zewnętrznego scope.

Przepraszam, nie wiedziałem, że bawisz się sam z polaczkiem ;p

Wiem o co chodziło więc zamiast Twojego przykładu zrobiłem tak

	{
		const int x = 666; 
		
		{
		enum {     x = x  };
		cout<<x;
		}
	
	}

w tym momencie po inicjacji const int x = 666; automatycznie enum przyjmuje wartość, myślałem, że trochę inaczej to działa. Tam gdzie jest konstruktor to const int x jest inicjowany dopiero przy wywołaniu konstruktora i to rozumiem, ale nie rozumiem, dlaczego w pierwszym przykładzie const int x = 666; nie działa ? const x nie powinien być inicjowany i dopiero potem przechodzić ? nie rozumiem tego za bardzo o_0 ?

Kompilator to z z visuala 2008pro, moje spostrzeżenia to jedynie breakpointy, niestety nie znam tak dobrze tego języka, żeby kompilować w głowie do tego stopnia ;p

Const int jest tylko dla picu, chodzi o stan wartości z wewnętrznego scope. Zewnętrzny jest inicjalizowany od razu, w tym pierwszym przypadku w momencie pojawienia się '=' zewnętrzna nazwa zostaje przesłonięta nazwę wewnętrzną, tej zmiennej co to jej dopiero wartość przypisujesz. Chodzi o to, że w każdym przypadku obowiązują inne zasady i w innym momencie zmienia się widoczność.

No tak, teraz ma to sens i nie ;p Rozumiem co sie dzieje, jednak hmm to nie powinno chyba tak działać, znaczy działa według implementacji, jednak można stosować to nieświadomie , przez przypadek....

Tylko że :

{ 
   const int x = 666; // gdy jestesmy w scope srodkowym zostaje przesloniete, jak wychodzimy juz nie.
	 { 
		int x = x;
		cout<<x;// wychodzą śmieci 
	 } 

	 cout<<x; //666
}

Z tego wynika, że jak wejdziemy do środkowego scope to nie dość, że przysłaniamy w tym zakresie zmienną to globalnie na okres przebywania w środku również ?

A jakby dwa wątki przeglądały ten kod i na raz jeden odwołuje się do środkowego x a jeden do zewnętrznego - co sie stanie ?

To zwykłe przesłanianie nazw, to dwie całkowicie różne zmienne zajmujące różne miejsce w pamięci. Po prostu nazywają się tak samo i do miejsca wyjścia z otaczającego scope jedna nazwa przesłania drugą. Wątki nie mają tutaj nic do rzeczy, to wyłącznie kwestia nazw widocznych na etapie kompilacji.

Ani jeden z kodow deusa nie skompilowal mi sie :) Moze to wina buildera?

Tak tylko dziwiłem się, że visual pokazuje mi na zewnątrz również przysłoniętego x, ale widocznie debugger pokazuje aktualny stan w jednej linijce lub to błąd czy tam inna funkcjonalność, bo moim zdaniem logicznym by było gdyby program wykonujący int x=x; przesłaniał x zewnętrznego, ale żeby ten x zewnetrzy nadal do tego samego miejsca pamięci był przypisany i nie przesłonięty sięgając do niego w tym samym momencie z zewnętrznego scope.

Z tego co mówisz on nadal jest przypisany, tylko na tą chwile debugger myśli, że to ten x ze środka ? ( wiesz po najechaniu myszką na zmienną pokazuje sie jej wartość)