W dniu środa, 9 stycznia 2019 08:46:07 UTC+1 użytkownik Maciej Sobczak napisał:
> > > Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla
końcowego odbiorcy.
> >
> > Mógłbyś wyjaśnić, co masz na myśli, mówiąc 'zbyt sztywny'?
>
> Np. to, że jego składnia jest ukłonem w stronę parserów a nie w stronę
użytkowników. Ja naprawdę wolę napisać a*b+c, niż (+ (* a b) c), i nie cieszy mnie
kończenie wyrażeń serią nawiasów tak długą, że nie sposób ich policzyć.

Programiści Lispa często wpadają na świetny pomysł dodania infiksowej składni dla
operatorów arytmetycznych do Lispa. To jest proste zadanie.
Później uświadamiają sobie, że mogą z łatwością dodać do Lispa taką składnię, jaką
sobie tylko wymarzą. (Trudno sobie wymyślić bardziej elastyczny język programowania)
Później - niektórzy - uświadamiają sobie, że inni też mogą łatwo wymyślać, i że tak
naprawdę żaden z tych pomysłów nie dodaje niczego, co by miało obiektywną wartość, i
że ich pomysły wyrażają tylko ich przesądy i dodają do języka przypadkową złożoność
(która np. jest trudna do objaśnienia 7-letnim dziewczynkom).
Richard Gabriel i Guy Steele nazwali ten proces "rytuałem przejścia".

> Wolfram jest o tyle ciekawy, że ma dwie albo trzy wewnętrznie równoważne składnie i
pozwala posłużyć się taką, jaka jest w danym miejscu odpowiednia.

Stephen Wolfram też ma za sobą rytuał przejścia.

> Jest to ważne zwłaszcza wtedy, gdy chcemy w języku wyrazić coś nowego, np.
wymagania albo zbiór danych.

Potrzebowałbym przykładu. Ale według moich doświadczeń jest niepotrzebne.

Tutaj mam np. "język dziedzinowy", w którym opisuję zasady gry w szachy:
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/schess/rules/ches
s.ss?at=default&fileviewer=file-view-default
a tutaj używam tego samego języka do opisania zasad wariantu wikingowskiej gry
planszowej "Hnevatafl":
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/schess/rules/ard-
ri.ss?at=default&fileviewer=file-view-default

Tutaj mam plik w swoim formacie do reprezentowania obiektów 3d:
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/art/3d/cube.3d?at
=default&fileviewer=file-view-default

a tutaj plik w formacie do opisywania układów fizycznych połączonych więzami,
reprezentujący robota humanoidalnego:
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/art/rigs/rob.rig?
at=default&fileviewer=file-view-default

Wszystkie te języki są oparte na Lispowych s-wyrażeniach.
Sprawia to, że parsowanie wszystkich tych formatów jest trywialne
(wystarczy do tego funkcja "read"), i do ich przetwarzania mogę
korzystać ze standardowych narzędzi, których używam też do swojego
języka programowania.

> > > Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe*
wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał,
że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji
imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać,
bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program
i napisać go od nowa (pokażesz?).
> >
> > Nie rozumiem przykładu
>
> Przykład pokazuje, że Twoja metoda funkcyjno-podstawieniowa tworzy zamknięty ciąg,
którego nie da się rozwijać. Poprosiłem o implementację nowego wymagania w tym samym
"projekcie". Pokażesz? Przecież stwierdziliśmy, że kod jest lepszy od słów.

Nie jestem pewien, czy rozumiem, ale jak dla mnie to "prawdziwość" tego stwierdzenia
mocno zależy od tego, jakie to konkretne będą wymagania.
Toteż chyba zamiast kodu będziesz się musiał zadowolić śmiesznym obrazkiem:
https://xkcd.com/1425/

> > Ja mam w tej kwestii zupełnie inne doświadczenia.
>
> Poproszę o implementację nowego wymagania w istniejącym projekcie.
> W wersji imperatywnej jest to oczywiste - dodatkowa zmienna, być może gałąź else.
Jak to będzie w Twojej wersji?

Bynajmniej nie jest oczywiste. To wszystko zależy od wymagania.
Czasem może trochę tak jest, że można wprowadzić zmiany w programie,
bez aktualizacji naszego aparatu pojęciowego. Niektórzy nazywają
to "wzorcem projektowym" "big ball of mud", a inni "długiem
technologicznym".

> > Pojęcia reprezentują nasze rozumienie składników rozwiązania. Jeżeli do wymagań
klienta dochodzi coś nowego, co nie jest wyrażalne przy pomocy dotychczasowego
aparatu pojęciowego
>
> Ale właśnie jest. "Te liczby, które nie są pierwsze, też można by do siebie dodać".
Co tu jest pojęciowo nowego? Liczby pierwsze, dodawanie - te pojęcia już masz, bo już
ich używałeś w programie. Teraz odwołując się do tych istniejących pojęć ja chcę mieć
też dodane do siebie te liczby, które nie były pierwsze.

To nie jest "zmiana wymagania".
To jest inny program
(ale części zdefiniowanych na potrzeby poprzedniego programu
pojęć będzie można użyć ponownie)

> > > 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy
podstawieniowej.
> >
> > Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż
nam, jak by dla niego taka analiza podstawieniowa wyglądała.
>
> A na jakie pytanie chciałbyś taką analizą odpowiedzieć?

Na przykład, jaki ten program da wynik dla argumentu "7".

> > Weź dowolną finansową aplikację. Tam tego typu prostych przekształceń będziesz
miał na pęczki.
>
> Weź dowolny system, który czegoś pilnuje albo czymś steruje.
> Jeszcze nie mówiliśmy o wymaganiach czasowych. Np. "woda w kranie w toalecie ma
przestać lecieć po 5s od ostatniej aktywacji czujnika zbliżeniowego". To wymaganie
jest pojęciowo bardzo proste.

Nie wydaje mi się, żeby było bardzo proste pojęciowo.
Ale zgodzę się, że sformułowanie jest bliskie naszemu codziennemu
doświadczeniu. I zgodzę się, że można znaleźć odpowiedni język
do rozwiązania tego problemu, i że niekoniecznie będzie to programowanie
funkcyjne.

> > Może niekoniecznie sumowanie kwadratów liczb pierwszych, ale na przykład liczenie
bilansu zysków i strat albo kwoty wolnej od podatku.
>
> Ale nawet w takim systemie wyobrażam sobie nowe wymaganie typu "a to coś co nie
spełniało warunku, to coś tam". I mam ten sam problem co z sumowaniem kwadratów.

Nie wiem. Nie bardzo rozumiem sformułowanie "a to coś nie spełniało
warunku, to cośtam".
Ale wydaje mi się, że z tego samego rodzaju problemami zmagają się
prawnicy - oni też nieraz próbują ująć złożoną rzeczywistość w prostych
słowach, i też im to nie zawsze wychodzi.
Cała afera z "dopalaczami" opierała się właśnie na tym, że dla
każdego sformułowania sprzedawcy tych substancji wyszukiwali wyjątki
z list substancji zakazanych.

> > A może warto ich uczyć na językach, których nie da się zastosować w większej
skali?
> >
> > Tylko wtedy mamy dydaktyczny problem zmiany skali.
>
> A może to nie jest problem nauki języka, tylko nauki inżynierii programowania? Może
właśnie tego brakuje adeptom powielającym złe nawyki z prostych przykładów? Ale język
jest wtedy drugorzędny.
> Przecież ten sam problem wystąpi w każdej innej dziedzinie - nie można oczekiwać,
że się nauczy kogoś architektury albo budownictwa na klockach. Tymczasem tak właśnie
ludzie podchodzą do nauki programowania - biorą książkę "Python w 24h" i jazda.

Wydaje mi się, że SICP wychodzi właśnie z takiego założenia,
że ich celem jest właśnie nauka "zarządzaniem złożonością".
Właśnie dlatego pierwsze dwa rozdziały poświęcone są w całości
zasadom abstrakcji, bo to abstrakcja - a nie algorytmy czy
struktury danych - są najbardziej podstawowym narzędziem do radzenia
sobie ze złożonością.

> > Wydaje mi się, że nie rozumiesz jednej rzeczy.
>
> > Jak ja Ci przedstawiam jakąś nową informację, to ja jej nie tracę, a stare
informacje nie znikają.
>
> A jeśli są wyświetlane na ekranie smartfona? Stare muszą zniknąć, bo rozmiar ekranu
jest ograniczony.

To i tak możesz do nich wrócić.

> > Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego.
>
> Ale możesz edytować tego nowego, gdy się pomylisz.

Sądzę, że to kwestia definicji. "Post" jest czymś, co zostało
"zapostowane".

> > To, że William Szekspir umarł, nie sprawia, że nie mogę o nim mówić, nie dostając
błędu segmentacji pamięci.
>
> Ale żółwika z nim nie przybijesz.
>
> > Jeżeli od jakiegoś momentu postanowimy, żeby słowem "jabłko" określać konia, nie
sprawi to, że nagle wszystkie jabłka staną się końmi, ani że wszystkie dotychczasowe
użycia słowa "jabłko" będą dla wszystkich oznaczać konie.
>
> Ten przykład jest dla mnie za trudny.

Właśnie ten jest najbardziej esencjonalny.

> > Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i
nie zamazujesz wszystkich swoich notatek.
>
> A jeśli piszę na tablecie?

To chyba też nie kasujesz swoich notatek?

> > Trudno to sobie uświadomić,
>
> Znowu mnie nie przekonałeś?

Jak mówię, nie spodziewałem się, że ten przekaz zostanie zrozumiany.
Nie wiem, jak to lepiej wyjaśnić.

> > Choćby w Pythonie mamy coś takiego:
> [...]
>
> Tak, Python jest źle zaprojektowany. Ale to nie jest przykład na problem z operacją
przypisania. Są języki, gdzie ten sam przykład zadziała prawidłowo i zgodnie z
intuicją.

Zgodnie z czyją intuicją?
Bo spotkałem osoby, które uznawały własnie takie zachowanie za pożądane.

> Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała poprawnie.

"Poprawnie", czyli tak, jak Ty uważasz, że jest poprawnie?

> > Prostota, o której ja piszę, nie jest prostotą implementacyjną, ale prostotą
pojęciową
>
> I to jest dobre określenie. Podoba mi się i zgadzam się z nim. Za wyjątkiem
oczywiście tego, że pomijanie aspektów implementacyjnych jest zwykle krótkowzroczne i
sprawdza się tylko w prostych albo jednorazowych (często te cechy są razem)
przykładach.

Ja bym raczej powiedział, że jest to pewien model, który jest prosty do nauki i
pozwala na unikniecie wielu błędów, ale który jest też ograniczony funkcjonalnie.

> Zgodzę się jednak, że prostota pojęciowa to dobry cel w wielu zastosowaniach. Myślę
jednak, że proponowane przez Ciebie rozwiązania zostaną kiedyś zastąpione przez coś w
rodzaju asystentów AI, jak Wolfram Alpha:
>
> https://www.wolframalpha.com/input/?i=sum+of+first+s
even+prime+numbers
>
> Jest prostota pojęciowa? Jest. Właściwie prościej się nie da.
> Pozostaje zastosować to w większej skali, np. systemu finansowego. Nie mam
wątpliwości, że taki jest właśnie kierunek rozwoju.

Ja też nie mam.
Ale składnia języka naturalnego moim zdaniem niezbyt dobrze nadaje się do
programowania.
Formalne notacje są dużo precyzyjniejsze (i właściwie po to zostały wymyślone)

do góry

W dniu środa, 9 stycznia 2019 09:08:24 UTC+1 użytkownik Maciej Sobczak napisał:
> > Spróbuj sformułować problem liczenia MD5 bez odwoływana się
> > do istniejących implementacji i dokumentów. Czekam.
>
> Źle. Jeśli ograniczasz swoją perspektywę tylko do problemów, które można
wytłumaczyć przez telefon, to sam sobie budujesz szklany sufit. Jednocześnie sam
sobie zaprzeczasz, bo twierdziłeś tutaj, że bardziej od słów cenisz sobie
hiper-precyzyjny zapis w postaci kodu. Dlaczego teraz przed tym uciekasz?

Nie uciekam.
Uważam, że sformułowanie problemu jest koślawe.
Określenie "zaimplementuj algorytm MD5" jest pojęciowo wtórne w takim sensie, że to
nie rozwiązuje żadnego problemu.
MD5 samo już jest rozwiązaniem pewnego problemu: "chcemy mieć funkcję skrótu o takich
a takich własnościach", albo "chcemy mieć program, który ma takie a takie własności
matematyczne, i które można wydajnie zaimplementować na takiej a takiej klasie
sprzętu".

> Algorytm MD5 jest opisany np. tutaj:
>
> https://en.wikipedia.org/wiki/MD5
>
> Jest tam sekcja Algorithm a pod nią Pseudocode.
>
> Istnieje spora szansa, że nie da się tego wyrazić prościej.
> Pytanie teraz, jak to zaprogramować. I w czym.

Moja odpowiedź jest taka, że ktoś już to zrobił. Jest implementacja, której możesz
użyć, którą możesz sobie przetłumaczyć, itp.
MD5 zostało zaprojektowane przez osobę o wysokim poziomie ekspertyzy w algorytmice.
Podejrzewam, że 99% programistów nie wpadłoby na coś podobnego.
Nie uważam, że to źle.
I nie jestem przeciwny temu, żeby ludzie stawali się ekspertami.
Jednak przypomnę, że tytuł tego wątku brzmi
"Jaki język polecić początkującemu".

do góry

On Tuesday, January 8, 2019 at 10:48:12 PM UTC+1, AK wrote:
> On 2019-01-08 17:21, Wojciech Muła wrote:
> 10 lat temu zrywaliscie boki jak nie gdze indziej niz tu "promowalem"
> Pythona.

No ja Cię proszę, jacy "wy"? Mogłeś napisać wszystko, nawet że
C++ ma dwa plusy, ale to? Przecież ja używam Pythona ponad 10 lat,
to jest mój drugi język (a czasem i pierwszy), piszę w nim
praktycznie codziennie, połowa mojego open-sourca jest stworzona
w Pythonie... normalnie nóż w plecy.

> 10 lat temu wieli glowny Mufti C++ niejaki Sekator van Skijlen
> zarykiwal sie gdy "promowalem" tu .NET-a/C#.
> No ze pojade klasykiem: i kto mial racje ?
> A gdzie bylo C++ w tym czasie? Ano (do czasu C++14, choc to tez
> przegadany syf...) byl w d... gdy inne jezyki sie rozwijaly.

Zmodyfikujmy nieco pytanie: gdzie teraz są inne języki, a gdzie
jest C++? Czy z C# ktoś korzysta poza Microsoftem i tymi pięcioma
osobami od Mono?

> Wumyslane problemy.
> W zyciu mi sie nie zdarzylo miec problemy ze stosowaniem i wydajnoscia
> koekcji Integer vs int, czy Double vs double.

To jesteś szczęściarzem, bo u mnie zabrakło pamięci. Chciałem
tylko mieć listę list integerów, żeby elegancko robić
wyszukiwanie po indeksach opartych na trigramach --- takie dość
efektywne podejście do pełnotekstowego wyszukiwania w dużych
zbiorach tekstów. Gdy piszę "dużych", to mam na myśli liczby
rzędu 100 milionów wierszy, czyli od 0.5G do 1GB znaczków.

I tu zaskoczenie: okazało się, że narzut pamięciowy wbudowanych
list był tak ogromny, że musiałem sobie wystrugać jakiś interfejs
na koślawy, prymitywny array arrayów (czyli int[][]), żeby
jakkolwiek dało się pracować z rzeczywistymi danymi. Na
szczęście nie musiałem się tym dłużej zajmować.

w.

do góry

On 2019-01-09 23:22, Wojciech Muła wrote:
> On Tuesday, January 8, 2019 at 10:48:12 PM UTC+1, AK wrote:
>> On 2019-01-08 17:21, Wojciech Muła wrote:
>> 10 lat temu zrywaliscie boki jak nie gdze indziej niz tu "promowalem"
>> Pythona.
>
> No ja Cię proszę, jacy "wy"? Mogłeś napisać wszystko, nawet że
> C++ ma dwa plusy, ale to? Przecież ja używam Pythona ponad 10 lat,
> to jest mój drugi język (a czasem i pierwszy), piszę w nim
> praktycznie codziennie, połowa mojego open-sourca jest stworzona
> w Pythonie... normalnie nóż w plecy.

Wy to nie znaczy tylko ty.
Wy to zdecydowana wiekszosc tutaj i na pl.comp.lang.c

>> 10 lat temu wieli glowny Mufti C++ niejaki Sekator van Skijlen
>> zarykiwal sie gdy "promowalem" tu .NET-a/C#.
>> No ze pojade klasykiem: i kto mial racje ?
>> A gdzie bylo C++ w tym czasie? Ano (do czasu C++14, choc to tez
>> przegadany syf...) byl w d... gdy inne jezyki sie rozwijaly.
>
> Zmodyfikujmy nieco pytanie: gdzie teraz są inne języki, a gdzie
> jest C++? Czy z C# ktoś korzysta poza Microsoftem i tymi pięcioma
> osobami od Mono?

Sorry, ale tu opala mi szczeka
Chyba rzeczywiscie skostniales "na starosc", zasklepiles sie w tych C++
i nie wiesz co sie dzieje poza tym ;).
PS: No a przecie blisko Ciebie jest takie malenstwo jak Autodesk.
Wystarczy spytac jak sie tam sprawy maja w kwestii .NET i C#.

Wystarczy spojrzec na ilosc ofert pracy tyczacych .NETa (a rzeczony
Sekator rowzniez skonczyl jako .NETowiec:)

>> Wumyslane problemy.
>> W zyciu mi sie nie zdarzylo miec problemy ze stosowaniem i wydajnoscia
>> koekcji Integer vs int, czy Double vs double.
>
> To jesteś szczęściarzem, bo u mnie zabrakło pamięci. Chciałem
> tylko mieć listę list integerów,
żeby elegancko robić
> wyszukiwanie po indeksach opartych na trigramach --- takie dość
> efektywne podejście do pełnotekstowego wyszukiwania w dużych
> zbiorach tekstów. Gdy piszę "dużych", to mam na myśli liczby
> rzędu 100 milionów wierszy, czyli od 0.5G do 1GB znaczków.
>
> I tu zaskoczenie: okazało się, że narzut pamięciowy wbudowanych
> list był tak ogromny, że musiałem sobie wystrugać jakiś interfejs
> na koślawy, prymitywny array arrayów (czyli int[][]), żeby
> jakkolwiek dało się pracować z rzeczywistymi danymi. Na
> szczęście nie musiałem się tym dłużej zajmować.

Nie kpij sobie :)
Po prostu nie uzyles gotowca jakim sa chocby rzeczone Eclipse
Collections.

AK

do góry

On Thursday, January 10, 2019 at 2:32:52 AM UTC+1, AK wrote:
> > Zmodyfikujmy nieco pytanie: gdzie teraz są inne języki, a gdzie
> > jest C++? Czy z C# ktoś korzysta poza Microsoftem i tymi pięcioma
> > osobami od Mono?
>
> Sorry, ale tu opala mi szczeka
> Chyba rzeczywiscie skostniales "na starosc", zasklepiles sie w tych C++
> i nie wiesz co sie dzieje poza tym ;).

Nie ukrywam, że mało interesuje mnie świat Microsoftu czy Oracla.
Odwiedziłem 2-3 razy targi pracy i była w zasadzie Java, Java
w wersji script, Python. C# pojawiło się tylko samo razy co C++,
czyli doświadczony drwal nie miałby problemu z policzeniem ich
na palcach.

Jedyną wartą odnotowania ofertę C# miała firma z siedzibą w Jeleniej
Górze. Przepięknym, spokojnym mieście, gdzie wsiada się w autobus
nr 15 i po jakimś czasie jest się u podnóża Karkonoszy. A stamtąd
to już blisko do np. Śnieżnych Kotłów. To tyle, jeśli chodzi
o zalety pisania w C#. :)

> > I tu zaskoczenie: okazało się, że narzut pamięciowy wbudowanych
> > list był tak ogromny, że musiałem sobie wystrugać jakiś interfejs
> > na koślawy, prymitywny array arrayów (czyli int[][]), żeby
> > jakkolwiek dało się pracować z rzeczywistymi danymi. Na
> > szczęście nie musiałem się tym dłużej zajmować.
>
> Nie kpij sobie :)
> Po prostu nie uzyles gotowca jakim sa chocby rzeczone Eclipse
> Collections.

Ale ja użyłem gotowca... z języka. :) W ten sposób możemy
powiedzieć, że Python też by sobie poradził, wystarczyło
wziąć numpy.

w.

do góry

On 2019-01-10 09:29, Wojciech Muła wrote:
> On Thursday, January 10, 2019 at 2:32:52 AM UTC+1, AK wrote:
>>> Zmodyfikujmy nieco pytanie: gdzie teraz są inne języki, a gdzie
>>> jest C++? Czy z C# ktoś korzysta poza Microsoftem i tymi pięcioma
>>> osobami od Mono?
>>
>> Sorry, ale tu opala mi szczeka
>> Chyba rzeczywiscie skostniales "na starosc", zasklepiles sie w tych C++
>> i nie wiesz co sie dzieje poza tym ;).
>
> Nie ukrywam, że mało interesuje mnie świat Microsoftu czy Oracla.

A szkoda, bo MS bardzo duzo zrobil w ostatniej dekadzie w tej kwestii.
.NET jest dzis bardzo dojrzalym, wbudowanym w system w pelni darowym
wieljezykowym srodowiskiem programistycznym.
Pod wzgledem jakosci na glowe bije Jave.

PS: Hmm... Byc moze jestem jednym z tych 5, ktorzy od lat korzystaja
(fakt ze nieprodukcyjnie) z Mono. A szkoda, bo moze zapyzialy
w sobie swiatek Lunksiarzy (systemu zerznietego wlasciwie 1:1
ze starego dobrego prawdziwego Unixa:) otworzul by szerzej oczy.
Az dziw bierze, ze przez tyle lat nie dorobil sie porzadnej
standardowej technologii komponentowej.
PS: Owszem byla szansa z Gnome, ale.. zwyciezylo "podejscie
estetyczne" i "wygralo" kde :)
Tymczasem na Windzie byl (wziaz jest i ma sie dobrze!) COM/DCOM,
a teraz zastapil go o wiele lepszy .NET.
To jest calkowicie inna jakosc/sposob tworzenia softy niz
przestarzale podejscie typu *.lib/*.a czy nawet *.dll/*so
PS1: Mnie cieszy ze Oracle popelnia ten sam blad zJava co kiedys
Sun:).Strezlaja se w stope/Jave sami chyba dobrze nei wiedzac
jak sie to dla Jawy z czasem skonczy. TymczasemMS wyciagnal nauki
ze zwych bledow i ustandaryzowal od poczatku C# (ECMA),
ostatnio w peni otworzyl kod .NETa i "upublicznil"/"udarmowil"
VStudio. To juz przynosci efekty, choc zabije to Mono
(ale i tak mu/Mono ede bardzo wdzieczny)

> Odwiedziłem 2-3 razy targi pracy i była w zasadzie Java, Java
> w wersji script, Python. C# pojawiło się tylko samo razy co C++,
> czyli doświadczony drwal nie miałby problemu z policzeniem ich
> na palcach.
>
> Jedyną wartą odnotowania ofertę C# miała firma z siedzibą w Jeleniej
> Górze.

Oj to sorry. Bylem przekonany ze pracujesz w Krakowie :).

>> Nie kpij sobie :)
>> Po prostu nie uzyles gotowca jakim sa chocby rzeczone Eclipse
>> Collections.
>
> Ale ja użyłem gotowca... z języka. :) W ten sposób możemy
> powiedzieć, że Python też by sobie poradził, wystarczyło
> wziąć numpy.

Alez oczywiscie !
Przeciez nie sam jezyk stanowi o jego "dobroci", ale tez jego otoczenie
(bblioteki, APIs, frameworki, comminity, zaszlsci/dorobek (tak, tu C++
wciaz jeszcze jest gora)

AK

do góry

W dniu czwartek, 10 stycznia 2019 10:14:11 UTC+1 użytkownik AK napisał:
> On 2019-01-10 09:29, Wojciech Muła wrote:
> > On Thursday, January 10, 2019 at 2:32:52 AM UTC+1, AK wrote:
> >>> Zmodyfikujmy nieco pytanie: gdzie teraz są inne języki, a gdzie
> >>> jest C++? Czy z C# ktoś korzysta poza Microsoftem i tymi pięcioma
> >>> osobami od Mono?
> >>
> >> Sorry, ale tu opala mi szczeka
> >> Chyba rzeczywiscie skostniales "na starosc", zasklepiles sie w tych C++
> >> i nie wiesz co sie dzieje poza tym ;).
> >
> > Nie ukrywam, że mało interesuje mnie świat Microsoftu czy Oracla.
>
> A szkoda, bo MS bardzo duzo zrobil w ostatniej dekadzie w tej kwestii.
> .NET jest dzis bardzo dojrzalym, wbudowanym w system w pelni darowym
> wieljezykowym srodowiskiem programistycznym.
> Pod wzgledem jakosci na glowe bije Jave.
>
> PS: Hmm... Byc moze jestem jednym z tych 5, ktorzy od lat korzystaja
> (fakt ze nieprodukcyjnie) z Mono. A szkoda, bo moze zapyzialy
> w sobie swiatek Lunksiarzy (systemu zerznietego wlasciwie 1:1
> ze starego dobrego prawdziwego Unixa:) otworzul by szerzej oczy.

Szczerze mówiąc, określenie "zapyziały światek linuksiarzy" brzmi nieco pogardliwie.
W moim doświadczeniu cały research w językach programowania, jaki jest godny
zainteresowania, odbywa się właśnie na Linuksie.
To, że teraz mogę w miarę swobodnie korzystać z Windowsa, zawdzięczam WSL (Windows
Subsystem for Linux) i projektowi MSYS.

I gwoli ścisłości, rzeczy, które są dobrze zrobione w Windowsie, właściwie też są
zerżnięte 1:1 ze "starego dobrego prawdziwego Unixa".
Niestety nie wszystkie. Tutaj jest dość interesujący wątek na Twitterze:
https://twitter.com/Foone/status/1058676834940776450

do góry

> Określenie "zaimplementuj algorytm MD5" jest pojęciowo wtórne w takim sensie, że to
nie rozwiązuje żadnego problemu.

To jest przykład rozwiązania problemu typu "napisz funkcję zgodnie ze specyfikacją".
Specyfikację określa klient. Jeżeli jest jakiś problem z tą konkretną funkcją, to
można wymyślić nieskończenie wiele innych funkcji, z którymi będzie taki sam problem.
Być możę trafię na taki problem w kolejnym projekcie robionym na zlecenie. Nie, nie
pomoże mi zwalenie winy na klienta.

Jest to też przykład rozwiązania problemu, którego być może w ogóle nie da się
rozwiązań inaczej, niż przez automat. Istnieją różne teorie na temat tego, jak można
jakiś problem opisać, istnieją nawet pewne minimalne zapisy, poniżej których nie da
się zejść. To jest zagadnienie ogólne. A ten konkretny przykład pokazuje, jakie są
ograniczenia podejścia funkcyjnego do zapisu różnych rzeczy. Być może trafię na taki
problem w kolejnym projekcie robionym na zlecenie LUB nawet we własnym, kreatywnym,
nawet nie mając ograniczeń narzuconych z zewnątrz. To by była szkoda, bo wtedy nawet
nie ma na kogo zwalić winy.

Problem jest fundamentalny i można go przedstawić tak: imperatywnie da się zapisać (i
rozwiązać) każdy problem, natomiast nie każdy problem da się zapisać funkcjonalnie. Z
tego wynika, że imperatywność jest bardziej uniwersalna jako narzędzie do
rozwiązywania problemów. I o tym jest ten przykład.

> Moja odpowiedź jest taka, że ktoś już to zrobił.

Nie o to chodzi. To jest przykład z pewnej klasy. Być może nieskończenie licznej.

> Jednak przypomnę, że tytuł tego wątku brzmi
> "Jaki język polecić początkującemu".

To jak to było w tym Twoim argumentem? Że łatwe rzeczy stają się trudne a o trudnych
można w ogóle zapomnieć?

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 2019-01-10 10:54, g...@g...com wrote:
>> PS: Hmm... Byc moze jestem jednym z tych 5, ktorzy od lat korzystaja
>> (fakt ze nieprodukcyjnie) z Mono. A szkoda, bo moze zapyzialy
>> w sobie swiatek Lunksiarzy (systemu zerznietego wlasciwie 1:1
>> ze starego dobrego prawdziwego Unixa:) otworzul by szerzej oczy.
>
> Szczerze mówiąc, określenie "zapyziały światek linuksiarzy" brzmi nieco
pogardliwie.

Bo ta ma brzmiec/bo tak wyglada rzeczywistosc.
Jesli zapyzialemu swiadkowi Linuksiarzy wolno jezdzic "jak po burej
suce" po np MS czy Windows, to i mnie wolno (a pamietaj ze mam inna
perspektywe, perspektywe czasow Unixa AT&T i pozniej SCO)
- fakt ze lagodniej niz oni traktuja MS/Win - potraktowac ich "ukochany
system". Czynie to merytorycznie wykazujac brak technologii
komponentowej w tym "nowoczesnym" OSie.

> W moim doświadczeniu cały research w językach programowania, jaki jest godny
zainteresowania, odbywa się właśnie na Linuksie.

Chyba zartujesz :)

> To, że teraz mogę w miarę swobodnie korzystać z Windowsa, zawdzięczam WSL (Windows
Subsystem for Linux) i projektowi MSYS.
>
> I gwoli ścisłości, rzeczy, które są dobrze zrobione w Windowsie, właściwie też są
zerżnięte 1:1 ze "starego dobrego prawdziwego Unixa".

Tak, ale nikt temu nie przeczy.
Natomiast swiatek Lunuxowy wcaz pieje jaki to ich system
"swiezy"/powstaly od 0, "nowoczesny" no i "wolny"
(heh unikane jak ogien w korporacjach GPL:).

AK

do góry

[Dzielę odpowiedzi na kawałki, bo nie lubię wielowątkowych wypracowań.]

> Programiści Lispa często wpadają na świetny pomysł dodania infiksowej składni dla
operatorów arytmetycznych do Lispa.

Nie chodziło konkretnie o operatory. Chodziło również o takie rzeczy jak możliwość
zapisania macierzy w czytelnej postaci, logikę, operacje na zbiorach, itd., użycie
bogatej symboliki operatorów (strzałki i takie tam), żeby nie wspomnieć o
bezpośrednim użyciu obiektów multimedialnych typu obrazek albo dźwięk.

> Później - niektórzy - uświadamiają sobie, że inni też mogą łatwo wymyślać, i że tak
naprawdę żaden z tych pomysłów nie dodaje niczego, co by miało obiektywną wartość,

Czytelność zapisu ma dla mnie subiektywną wartość, którą cenię. Już o tym pisałem.

> > Wolfram jest o tyle ciekawy, że ma dwie albo trzy wewnętrznie równoważne składnie
i pozwala posłużyć się taką, jaka jest w danym miejscu odpowiednia.
>
> Stephen Wolfram też ma za sobą rytuał przejścia.

?

W ogóle nie rozumiem tego zdania.
Ani tym bardziej, czy to dobrze, czy źle. A to ważne, bo nie wiem, czy mam się z tym
zgodzić, czy nie zgodzić.

> Tutaj mam np. "język dziedzinowy", [...]
>
> Wszystkie te języki są oparte na Lispowych s-wyrażeniach.

Fajne. Nieczytelne. Trudno namówić klienta albo inną osobę spoza projektu do
współpracy nad takimi plikami.

> Sprawia to, że parsowanie wszystkich tych formatów jest trywialne

Nie obchodzi mnie, czy jest trywialne. Jak to było? Po co rozwiązywać problem, skoro
można go ominąć? To nie ja to parsuję.

> (wystarczy do tego funkcja "read"), i do ich przetwarzania mogę
> korzystać ze standardowych narzędzi, których używam też do swojego
> języka programowania.

Dokładnie to samo można powiedzieć o Wolframie (dlatego piszę, że parsowanie to nie
mój problem), ale efekt końcowy jest czytelniejszy, jeśli mam do dyspozycji coś
więcej, niż tylko okrągłe nawiasy.

--
Maciej Sobczak * http://www.inspirel.com

do góry