Jakie języki programowania warto znać / Jakie języki znacie

[przemeksag]

Witam

Na świecie istnieje duża liczba języków programowania C++ , Pascal, Basic, itp.
Przy tej ilości ciężko wybrać coś konkretnego nad czym warto się skupić i w czym warto "orać".
Oczywiście możecie powiedzieć, że wystarczy poznać jeden a poznanie reszty to tylko poznanie składni. Oczywiście się z tym zgodzę ale do pewnego stopnia, ponieważ w taki sposób można poznać dany język pobieżnie i żeby robić naprawdę ciekawe projekty trzeba się w taki język wgryźć i poznać dokładnie jego składnie a to przekłada się na jakże cenny czas który trzeba nad tym spędzić a wiadomo że wszystkiego nie da się nauczyć. Dlatego kieruje do Was pytanie jakich języków najlepiej się uczyć? Oczywiście wiem, że zależy to od przeznaczenia języka ale przyjmijmy zastosowania takie jak elektronika (uC) , typowy soft , obliczenia numeryczne , języki/programy do szybkich obliczeń typu Mathematica Matlab.

[Luminofor]

Do tych zastosowań co wymieniłeś to: C++ (do wszystkiego), asembler (procki), Matlab (numeryczne).

Zwłaszcza polecam C++, jest do tego świetna literatura (J. Grębosz) i jest to język uniwersalny, na prawdę warto go znać.

[przemeksag]

Co do C++ zgodzę się bez wahania. Mam jednak wątpliwości co do Asemblera i Matlaba.
Matlab jest środowiskiem o stosunkowo małych możliwościach algebry komputerowej w porównaniu do Mathematic-y dlatego myślę że w kategorii "małe" obliczenia numeryczne wygrywa jednak Mathematica jedyną zaletą Matlaba jest to że potrafi wczytywać bezpośrednio dane pomiarowe.

Natomiast co do Asemblera czy nie jest zbyt uciążliwy w tworzeniu programów. Chodzi mi o to że Bascom jest łatwiejszy (czysto subiektywne odczucie) ponieważ można powiedzieć że "aseblerów" jest tyle ile procków . A jedyną zaletą asm jaką znam jest to że zajmuje mniej pamięci.

[Luminofor]

Matlab w połączeniu z Simulinkiem daje naprawdę ogromne możliwości, np. w kilka minut możesz sobie zasymulować kanał radiowy sieci GSM (Simulink ma gotowe toolboxy i tylko łączy się odpowiednie bloczki). A sam Matlab także ma ogromne możliwości, chociażby przy przetwarzaniu grafiki.

[keruseykaryu]

Natomiast co do Asemblera czy nie jest zbyt uciążliwy w tworzeniu programów.

Nie. Tylko trza wiedzieć co się chce osiągnąć, podzielić to na moduły i napisać.
Napisałem kiedyś dwie wersje zegarka pod 8051. Jedna w Bascom, bo komuś chciałem pokazać, Druga w asemblerze. Obie chodziły, ale kod w asemblerze zajmował ~600 bajtów, a Bascom to zmieścił dopiero w 1,5KB.

Chodzi mi o to że Bascom jest łatwiejszy

No szło by się kłócić. Tam nie wiesz nic co kompilator z tym kodem zrobi. Potem dopiero się dowiadujesz, że jakieś przerwanie się kłóci z jakąś tam komendą, i że i tak się program sypie bo nie zadbałeś o stosy.

A jedyną zaletą asm jaką znam jest to że zajmuje mniej pamięci.

To znasz jedną. Poza tym ASM: pełna kontrola nad procesorem, przewidywalność czasu operacji, Ty piszesz = Ty optymalizujesz.

[przemeksag]

Natomiast co do Asemblera czy nie jest zbyt uciążliwy w tworzeniu programów.

Nie. Tylko trza wiedzieć co się chce osiągnąć, podzielić to na moduły i napisać.
Napisałem kiedyś dwie wersje zegarka pod 8051. Jedna w Bascom, bo komuś chciałem pokazać, Druga w asemblerze. Obie chodziły, ale kod w asemblerze zajmował ~600 bajtów, a Bascom to zmieścił dopiero w 1,5KB.

Chodzi mi o to że Bascom jest łatwiejszy

No szło by się kłócić. Tam nie wiesz nic co kompilator z tym kodem zrobi. Potem dopiero się dowiadujesz, że jakieś przerwanie się kłóci z jakąś tam komendą, i że i tak się program sypie bo nie zadbałeś o stosy.

A jedyną zaletą asm jaką znam jest to że zajmuje mniej pamięci.

To znasz jedną. Poza tym ASM: pełna kontrola nad procesorem, przewidywalność czasu operacji, Ty piszesz = Ty optymalizujesz.

I takie odpowiedzi lubię . Pytam bo chce się dowiedzieć czegoś więcej ponieważ każdego z tych języków tylko trochę dotknąłem a właściwie to tylko musnąłem a teraz przyszedł moment na to aby wziąć się do nich na poważnie i muszę coś wybrać bo ze wszystkimi się nie wyrobie..
Głównym celem tego postu jest jakby przejrzenie różnych możliwości czego się uczyć. Jak dobrze pójdzie to niedługo (za 4 lata ) będę fizykiem i u nas na wydziale "rządzi" C++ , Mathematica, i root (nie wiem czy to się tak pisze) ten ostatni służy przeważnie do fitów ale słyszałem że np w CERNIE niektórzy jeszcze tłuką coś w Fortranie.

[kayron]

Tzn. C na pewno jest językiem uniwersalnym i szeroko rozpowszechnionym. Co do ASM to sprawa tu nie wygląda tak jasno i klarownie, bo to zależy o jakim ASM i dla jakich procesorów mówimy. Dla 8-bitowców faktycznie najgorzej nie jest, ale nie widzę uśmiechu na twarzy początkującego na ASM choćby 8086 z kooprocesorem 8087 (286 położył by pewnie 90% chętnych), nie wspominając o procesorach 32 bitowych z DSP.
W przypadku ASM dużo zależy od złożoności architektury samego CPU.
Najważniejszą zaletą ASM jest możliwość optymalizacji, do granic możliwości, ale pytanie brzmi kto dzisiaj optymalizuje kod, mając za 2zł więcej 2-3x szybszy proc do wyboru ?

[mr_x]

Jeśli o mnie chodzi, kiedyś pisałem w BASIC. Trochę C++, ale to dosłownie liznąłem tylko. Obecnie skrypty w BASH oraz asembler 8051.

W ankiecie brakuje właśnie asemblera (również x86).

[edwacc]

Programuje w jezykach C, C++, Java, ASM, C#, BASH, Python, Perl. W C++ i C zawodowo od paru lat.
Nie podzielam zachwytu niektorych co do jezyka C++. Jest to jezyk na pograniczu niskiego i wysokiego poziomu, latwo w nim o wpadke z memory leak, czy inne tego typu bledy.

Jedynym naprawde uniwersalnym, wszechstronnym jezykiem jest jezyk C. Stosowalem go na kazdym etapie projektow. Od projektow embeded na AVR do bazodanowych.

A jesli ktos chce zapomniec o wskaznikach to polecam Jave.

[keruseykaryu]

ale pytanie brzmi kto dzisiaj optymalizuje kod, mając za 2zł więcej 2-3x szybszy proc do wyboru ?

Nie "kto" tylko co: Rachunek opłacalności. Bo bywa tak - oj, bywa - że projekt ma się zmieścić w ustalonej cenie i takie ruchy +2zł to zabójstwo finansowe.

[Luminofor]

edwacc, przecież C jest bardziej niskopoziomowy od C++ !

[kayron]

Nie "kto" tylko co: Rachunek opłacalności. Bo bywa tak - oj, bywa - że projekt ma się zmieścić w ustalonej cenie i takie ruchy +2zł to zabójstwo finansowe.

Mówisz chyba o projektach komercyjnych (nastawionych na zysk, przy min kosztów Hardweru), bo typowy Hobbysta niekoniecznie trzyma się tej zasady. Można by sypać projektami gdzie proste rzeczy robi się na nieproporcjonalnie potężnych do tego CPU, czy jakimiś dziwacznymi metodami programistycznymi. Ale jest to raczej wynik sytuacji zrównania się cen 8 i 32b CPU.

[edwacc]

edwacc, przecież C jest bardziej niskopoziomowy od C++ !

Nie powiedzialbym ze jest bardziej niskopoziomowy.. raczej że C++ umozliwia latwiejsze programowanie na wyzszym stopniu abstrakcji.
Programista C++ ma za duzy stopien swobody jesli chodzi o dostep do pamieci, przez co oprogramowanie w C++ najczesciej sie sypie.
Przykladem jest chociazby znany problem strict aliasing:http://cellperformance.beyond3d.com/art ... asing.html

[kayron]

Programista C++ ma za duzy stopien swobody jesli chodzi o dostep do pamieci, przez co oprogramowanie w C++ najczesciej sie sypie.

Ja bym raczej powiedział że przyczyny sypania sie softu są 2:
- wspomniana przez kolegę keruseykaryu tgz. opłacalność, czyli cięcie kosztów gdzie tylko się da.
- Żyjemy w czasach w których wszystko co ma sens już zrobiono, więc aby napędzać tgz. rozwój technologiczny do wszelkich urządzeń, maszyn, pojazdów zaczyna się wszczepiać coraz głupsze wynalazki i gadźety. Oczywiście w imię więcej-taniej co oznacza często byle jak, bez patrzenia czy to ma sens i jest użyteczne. Przykład choćby reklama RENUALT, czy FORDa, które nie reklamują już powoli swoich samochodów, tylko bajery w nich.

[keruseykaryu]

- wspomniana przez kolegę keruseykaryu tgz. opłacalność, czyli cięcie kosztów gdzie tylko się da.

Nie widzę związku. Przykład. Napisałem firmware, pierwotnie miało być w procku z 8KB, dając 60% full. Potem pocięliśmy koszty i ostatecznie firmware - rozpisane od nowa i inny kompilator - zmieściło się w procku z 4KB z 98% full. Funkcjonalność się nie zmniejszyła. Optymalizacja i zmiana kompilatora pomogła w 100%. Urządzenie się nie sypie - przynajmniej jak do teraz odbiorca nie zgłasza problemu.
Inny priklad? OK. Inne ustrojstwo. Miało mieć tiny25, kod w bascom napisany na szybko. Znowu cięcie. Ma tiny13a. Kod przeportowany do gcc, ledwo się mieści, jedna funkcja ukrócona bo okazała się nie potrzebna. Prototypy działają. Seryjna? Nie wiem czy będzie, bo był kryzyz i pół biura konstrukcyjnego u odbiorcy poleciało.
No nie wiem, ale od 5 lat robimy/robię OEMy i nie było związku pomiędzy cięciem kosztów, a sypaniem się softu.