Projekt jaki-jezyk-programowania.pl - ocena i feedback

dobra ludzie, myślę, że autorzy (czy obecnie chyba autor) dostał solidną dawkę porad i wystarczy, każdy kiedyś zaczynał więc nie ma co się znęcać na siłę ;)

czysteskarpety napisał(a):

dobra ludzie, myślę, że autorzy (czy obecnie chyba autor) dostał solidną dawkę porad i wystarczy, każdy kiedyś zaczynał więc nie ma co się znęcać na siłę ;)

Dzięki za wsparcie na duchu haha! :D Ale spokojnie, nie traktuję krytyki jako czegoś złego. Wręcz przeciwnie. Gdyby nie ona to wiele bym się nie nauczył. Jednak to, że obecnie strona jest słabej jakości, że mam niewielkie doświadczenie i pojęcie o tym wszystkim i że jestem leszczem programowania już wiemy :D Żałuję tylko, że nie inaczej założyłem tu wątek, bo wiele ważnych rzeczy nie dopowiedziałem (m. in. to co wymieniłem). No, ale wyszło w praniu ;) Myślę, że możemy się już skupić konkretnie nad poprawą jakości strony. Mam nadzieję, że wytrwacie tu ze mną ;)

Ta strona to ogólnie chyba zbiór popularnych mitów i informacji nieaktualnych o jakieś 15 lat. (Tak patrząc chociażby po "artykule" o C#).

fasadin napisał(a):

zrezygnowano z jego wielu kłopotliwych i nie eleganckich właściwości.

klopotliwych? nieeleganckich (blad macie na stronie, tam nie powinno byc spacji). Jezeli chodzi wam o wskazniki to w C++ od 6 lat ich uzywanie jest antyidomem. OD 6 LAT

@fasadin Podałbyś mi na szybko definicję słowa "antyidom"? Stworzyłeś nowe słowo, czy jak? Żeby nie było to próbowałem znaleźć to w google, ale jedyne co znalazłem to 3 posty na forach, które to Ty napisałeś ;). Domyślam się znaczenia, ale chciałbym je poznać :D.

Poprawiłem Jave (...), dziś postaram się jeszcze wziąć za C++/C# - Codeboy dziś, 09:01

Nie wiem, jak dla mnie tekst nadal jest pełen nieścisłości i przeinaczeń.

Java to obiektowy, wysokopoziomowy język programowania ogólnego zastosowania, który jest w pełni przenośny, gdyż jest interpretowany przez wieloplatformową maszynę wirtualną Javy (Java Virtual Machine).

Java jest przenośna do momentu, kiedy będziemy potrzebowali interakcji z systemem operacyjnym albo sprzętem, wtedy ta przenośność się znacznie ogranicza. Sporo "real life" programów wprowadza różne dodatkowe założenia dotyczące przenośności, ponieważ potrzebują skorzystać z rzeczy do których nie ma uniwersalnego API pomiędzy różnymi systemami/sprzętami/etc.

Dlatego powstał slogan „Napisz raz, pracuj wszędzie!”.

Write once, run everywhere. run = pracuj? wtf?

Java posiada także wiele wbudowanych bibliotek z gotowymi rozwiązaniami w przeciwieństwie np. do C++, do którego niektóre biblioteki musimy znaleźć, wybrać i dołączyć na własną rękę.

No nie wiem czy w chwili obecnej nie jest odwrotnie. Biblioteka standardowa nowoczesnego C++ to jest przepaść w porównaniu do biblioteki standardowej Javy (w sensie że Javowa jest dosyć uboga).

Java abstrahuje (zajmuję się tym za Ciebie) od sprzętowych detalów takich jak np. zarządzanie pamięcią

Zarządzanie pamięcią jest detalem sprzętowym wyłącznie na poziomie procesora i systemu operacyjnego, na wyższych poziomach dostęp do pamięci mamy wyłącznie przez zapewnione nam abstrakcje, które ukrywają faktyczną implementację sprzętową. Zarządzanie pamięcią jest raczej problemem konkretnego programu, który Java rozwiązuje poprzez model pamięci uwzględniający Garbage Collector.

więc możesz skupić się na programowaniu zamiast martwić się o rzeczy, które wielu uważa za żmudne, czy trudne

Tak brzmi marketing, rzeczywistość jest nieco bardziej brutalna. Początkujący programista Javy ma szereg możliwości, aby zrobić trudnego do znalezienia memleaka, chociażby używając klas anonimowych, które zostawiają "niewidzialne referencje": http://stackoverflow.com/a/10968689

Java jest językiem statycznym, co oznacza, że twój kod zostanie sprawdzony w celu znalezienia błędów zanim zostanie przetworzony, więc łatwiej je namierzyć.

Nie jest powiedziane, że chodzi konkretnie o sprawdzanie zgodności typów. Poprawnie powinniśmy powiedzieć "statycznie typowanym". Nie cały kod zostanie sprawdzony, a jedynie jego składnia oraz właśnie zgodność typów przepływających przez wywoływane metody, przypisywanych do zmiennych itp.

Javę cechuję także silne typowanie, to znaczy, że wyrażenia mają ustalony typ danych. Zapobiega to powstawaniu dziwnych i niespodziewanych błędów, więc kod jest łatwiejszy w utrzymaniu.

Silne typowanie nie musi iść w parze ze statycznym typowaniem, więc należałoby wspomnieć, że w silnym typowaniu chodzi o to, że zmienna raz stworzona nie może w międzyczasie zmienić swojego typu danych.

Bugi są dosyć szybko naprawiane a ilość narzędzi i bibliotek dostępnych dla Javy nie będzie łatwa do zastąpienia.

Chciałbym zobaczyć źródło tego zdania: "bugi są dosyć szybko naprawiane", bo jak rozmawiam ze znajomymi Javowcami (dowód anegdotyczny, ha!) to pokazują mi swoje zgłoszenia błędów, które wiszą nierozwiązane od kilku lat.

W kolejnych latach Java raczej nigdzie się nie wybiera, będzie kontynuować swoja dominacje.

Zgodzę się w części "nigdzie się nie wybiera". Ten język przeżywa(ł) ogromny zastój przez lata i dzięki temu jest sto lat za murzynami. Potęga Javy leży w legacy code, podejrzewam że do nowych projektów chętniej jest teraz wybierany konkurencyjny C#.

No nie wiem czy w chwili obecnej nie jest odwrotnie. Biblioteka standardowa nowoczesnego C++ to jest przepaść w porównaniu do biblioteki standardowej Javy (w sensie że Javowa jest dosyć uboga).

Nie jestem miłośnikiem bilioteki stanrdowej Javy - bo duża jej część wygląda nadal jakby robili ją programiści C w latach 90-tych... co zresztą jest prawdą i można wiele zarzucić prawie każdemu pakietowi.
Ale napisanie, że jest uboga to lekkie nadużycie (masz tam wsio od obsługi sieci, plików, wątkow, kryptografii, formatów graficznych, i18 aż do absurdów typu 3 bilioteki UI (awt, swing, javafx).
Pytanie - czego wg Ciebie tam nie ma?

Monk Monkowski napisał(a):

Poprawiłem Jave (...), dziś postaram się jeszcze wziąć za C++/C# - Codeboy dziś, 09:01

Nie wiem, jak dla mnie tekst nadal jest pełen nieścisłości i przeinaczeń.
...

Dzięki za kolejną garść uwag. Poprawiłem tylko to na co zwrócił uwagę @fasadin, nie twierdzę, że to są już gotowe opisy. Jeszcze pewnie nie raz będę je przeredagowywał. Ale jak najbardziej takie review od Was bardzo mi pomaga ;). Część z tych informacji była z książki o której wspominałem wcześniej, ale widzę, że trochę ją tam na siłę faworyzowali ;) Z kolei mam wrażenie, że ty trochę po niej ciśniesz :D

jarekr000000 napisał(a):

Pytanie - czego wg Ciebie tam nie ma?

Pomieszały mi się argumenty, w poście wyżej miał być C# (przede wszystkim w związku z tym, że poziom abstrakcji Javy i C# jest zbliżony), natomiast jeśli chodzi o wspomniany C++ to chciałbym zauważyć chociażby jak wygląda rozwój biblioteki standardowej Javy i C++. Java uparła się przy jakiejś dziwnej kompatybilności wstecznej, pomimo że niby można w kompilatorze ustawić jakiś source level (-source 7) i to zmienia sposób kompilacji (poprzez dodanie nowych ficzerów). Mogliby nakazać kompilowanie starego kodu na niższym source levelu, a na wyższych levelach wprowadzić jakieś niekompatybilności, wtedy byłby wilk syty i owca cała. Tymczasem (chyba że o czymś nie wiem) unikają łamania kompatybilności jak ognia i każda zła decyzja projektowa podjęta kiedykolwiek musi być utrzymana (chyba że jest jakiś ewidentny bug), dlatego ten stdlib wygląda jakby był z lat 90. Nie można tam nic zmienić, można tylko dodać. To jest wielka kula śnieżna.

Z punktu widzenia nowicjusza (bo tak patrzy na to omawiany w tym wątku projekt) na pewno na pierwszy rzut oka uderzy rozwlekłość różnych wraperów. Przytoczę metodę czytania pliku o określonym charsecie dostępną od Javy 1.7:

Charset charset = Charset.forName("US-ASCII");
try (BufferedReader reader = Files.newBufferedReader(file, charset)) {
    String line = null;
    while ((line = reader.readLine()) != null) {
        System.out.println(line);
    }
} catch (IOException x) {
    System.err.format("IOException: %s%n", x);
}

Gdzie metoda newBufferedReader to skrót, który wygląda tak:

public static BufferedReader newBufferedReader(Path path, Charset cs){
 CharsetDecoder decoder = cs.newDecoder();
 Reader reader = new InputStreamReader(newInputStream(path), decoder);
 return new BufferedReader(reader);
}

(Źródło: http://www.programcreek.com/2011/03/java-read-a-file-line-by-line-code-example/ )

Podczas normalnego programowania musimy dobierać i łączyć ze sobą różne dekoratory w odpowiedniej, zazwyczaj idiomatycznej (nie mylić z idiotyczną) kolejności. Ewentualna pomyłka powoduje straty wydajności. Jest to tak rozwlekłe, że sami Javowcy kombinują jak programować w Javie nie programując w Javie. Przykład powyższego w Scali:

import scala.io.Source
for(line <- Source.fromPath("myfile.txt").getLines())
  println(line)

Dlaczego tam można wykonać tę prostą czynność znacznie szybciej? Oczywiście dynamiczne typowanie i przyjaźniejsza składania robią swoje, ale nadal należy zauważyć że poprzez zapewnienie metody Source.fromPath cała sprawa została bardzo mocno ułatwiona. Tej cechy "ułatwiającej" nie wykazuje natomiast w wielu aspektach stdlib Javy.

Jeszcze w celu sprostowania jednej rzeczy - odnośnie listingu ze Scalą powołałem się na przestarzałe źródło, dodatkowo w listingu brakuje wyboru kodowania, żeby faktycznie było równoważne. Powinno być:

Source.fromFile(nazwa_pliku : String, kodowanie : String)

Aczkolwiek nie wpływa to na moją argumentację w żaden istotny sposób.

Monk Monkowski napisał(a):

jarekr000000 napisał(a):

Pytanie - czego wg Ciebie tam nie ma?

Pomieszały mi się argumenty, w poście wyżej miał być C# (przede wszystkim w związku z tym, że poziom abstrakcji Javy i C# jest zbliżony),

Zaraz zaraz, chcesz powiedzieć, że biblioteka .net jest uboga?

Krwawy Młot napisał(a):

Zaraz zaraz, chcesz powiedzieć, że biblioteka .net jest uboga?

Nie. Chciałem pokazać C++ jako wzór modernizacji stdliba i C# jako "podobny" język z przewagą nad Javą w tym aspekcie. Dodatkowo na korzyść C# przemawia chociażby wbudowana integracja z innymi produktami ze stacka MS.

Przebudowałem sposób wyświetlania funkcji w laptopie i na przykład dałem wyszukiwanie binarne. Wszystkie programy działają. Do napisania mi zostało jeszcze w C, C# i R. Formatowanie stosuję javowe bo tak jestem przyzwyczajony, jeśli dla któregoś języka styl Allmana jest odpowiedniejszy to dajcie znać ;) Myślę, że funkcje są już lepszej jakości, dajcie znać jak jest ;)

Wszystkie wasze sugestie dotyczące informacji o językach(JS,java,c++,c,python) (C# tylko "Zastosowanie") już poprawione.

Dzięki wszystkim którzy pomagają i oczywiście czekam na więcej ;)

PS: Dziwiliście się, że aż 3 osoby były do tego potrzebne - teraz została tylko jedna, lepiej? :D

return "Znaleziono \""+x+"\" na pozycji "+(middle+1);

Serio? Implementacje algorytmów służą do tego, żeby ich potem gdzieś użyć, a nie printować sobie ładne wiadomości na konsolę. W jaki sposób użyłbyś takiej implementacji w jakimś programie?

return middle+1;

Tyle. Wszystko. Zwracany wynik musi być użyteczny, inaczej istnienie funkcji nie ma sensu.

Btw. nie wiem czy w ogóle dodawanie tej jedynki ma jakikolwiek sens w językach gdzie indeksuje się od zera.

Zdaję sobie z tego sprawę, ale zrobiłem tak z dwóch powodów: żeby była od razu informacja dla zielonych jaki jest wynik + pokazać konkatenacje stringów z intami w rożnych językach. Wiem, że normalnie nie znajdzie zastosowania taki algorytm, ale on nie jest od tego. Tu służy tylko jako przykładowy kod, który pokazuję mniej więcej podstawową semantykę języka. Ewentualnie mogę to rozpisać na dwie funkcję, jedna to czysty algorytm, a druga printująca wynik. Miałem ten dylemat na początku ;) Myślisz, że to będzie lepszy pomysł? ;)

zresztą wydaje mi się, że to nie ma sensu, bo to jest kwestia usunięcia tylko stringa i algorytm już jest gotowy, a do potestowania sobie jak to działa jest w sam raz. Zresztą nikt go nie będzie implementował do swojego kodu czy coś, przecież sortowanie jest wszędzie :D

Tzn. w "prawdziwym życiu" (zawsze sie zastanawiam które to nieprawdziwe życie) robi się tak:

var wynik = funkcjaCoSzuka(zbior, x);
console.log("Znaleziono element " + x + "na pozycji " + wynik);

Strona mówi o "profesjonalnym" podejściu, to niech będzie zrobione po ludzku.