> > Bo to jest przypisanie. Tak się właśnie definiuje funkcje.
>
> NIE!

Sorki, ale z dokumentacją bym nie walczył. Jeszcze raz:

http://reference.wolfram.com/language/ref/SetDelayed
.html

"lhs:=rhs
assigns rhs to be the delayed value of lhs. [...]"

To jest przypisanie. Tak się właśnie definiuje funkcje. (W Wolframie)

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

do góry

W dniu piątek, 25 sierpnia 2017 06:38:23 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <p...@g...com> napisał:
>
> > Jakiś język programowania kompilowany do C można napisać :)
>
> > org-asm juz prawi zrobiony tak ze
> > niedlugo bede mogl robic wlasne kompilatory kompilujace do exe,
> > firr nie chodzi na kompromisy ;c
>
> ...ale na manowce...
>
> Chopie, kompilator kompilujacy C do asm/exe to pikus
> _Dobry_ kompilator C to kupe roboty (juz przez innych zrobionej!) i nie starczy Ci
> (biblioteki systemowe w stylu WinAPI) zycia !
>
> PS: chcesz to ci dam biblioteke standardowa C w asm86. Napisana w 87r "z musu".
> Pomoze Ci odzyskac troche czasu na normalne zycia miast na takie "idee" jak ta
Twoja ...
> PS0: jeszcze biblioteke BGI-zgodna dorzuce (88r) w czystym asm. Warto. Bedziemy Cie
> miec na dluzej z glowy :)))
>
> AK

biblioteka c jest mi nie potrzebna bo w moim asemblerze piszesz z
marszu

call msvcrt.cokolwiek

i od razu masz wywolanie dowolnej funkcji

do tego asembler napisalem praktycznie w tydzien (chyba nawet niecaly) [pmijam maly
300 linijkowy krytyczny kawalek kodu z naglowkami pe ktory napisalem i przetestowalem
z pol roku czy rok temu..] (rozcykiwanie formatu exe jest mulace ale jak o juz zrobic
to reszte da sie napisac w tydzien)

esencjalny okrojony kompilator c pewnie tez daloby sie napisac w mniej niz miesiac -
biblioteka jak
wspomnielem nie jest potrzebna bo dzis masz dll-ki - calkiem dobry wynalazek

do góry

> > Faktycznie koszmarek.
>
> Najgorsze jest to, że Stroustrup sam do czegoś takiego zachęcał.

Tak, była taka moda, żeby zamiast pisać jawne pętle, składać wszystko z funktorów i
algorytmów STL. To była głupia moda, na szczęście minęła.

> Na matematyce uczono mnie, żeby f(x) czytać jako "f od x" albo
> "wartośćć f w punkcie x". Nie uczono mnie, jak czytać [[_ ;; ;; _]]

Ja się programowania nie uczyłem na matematyce i nie szukam w matematyce odpowiedzi
na wszystkie programistyczne pytania. :-P

> > > Wątpliwości w dalszym ciągu wzbudza rola podkreślnika po argumencie
> > > po lewej stronie znaku ":=",
> >
> > To jest wzorzec, [...]
>
> Napisałem "wątpliwości", a nie "ciekawość" ;]

Akurat jedno i drugie leczy się tak samo, więc i tak musiałem odpowiedzieć. :-)

> > Bo to jest przypisanie.
>
> Może w Mathematice, ale nie w matematyce.

Każdy język programowania ma coś inaczej, niż w matematyce. Nikt nie robi z tego
problemu.

> To nie jest wciskanie ludziom kitu. Rekurencja w ogólności
> jest prostsza do zrozumienia dla ludzi.

Nie zgadzam się.

> Jeżeli spojrzeć na
> rzeczy, które dzieją się w logice, to praktycznie wszystkie
> podstawowe aksjomatyki mają charakter rekurencyjny,

Bo ktoś się uparł je tak definiować.
Poza tym, napisałem, że *w naturze* nie ma takich procesów. To, że w jakiejś
dziedzinie matematyki są takie definicje nie sprawia, że koncepcja rekurencji staje
się przez to naturalna.

> a bardzo
> wiele dowodów jest indukcyjnych.

To jest ciekawy przykład, ale do dyskusji. Indukcja działa na zasadzie "skoro dożyłem
do dzisiaj, to do jutra pewnie też dożyję" a to jest dla mnie domniemana iteracja w
sensie naturalnego procesu. Ale nie będę się upierał przy takiej filozofii. Tak czy
inaczej rekurencja w naturze nie występuje.

> Istnieje wiele zagadnień,
> na przykład w kombinatoryce i teorii języków,

Owszem. Nadal nie ma ich w naturze.

> Ja swoje stanowisko dotyczące C++ staram się jasno artykułować.
> W moim odczuciu to nie jest dobry język do formułowania myśli.

To jest dobry język do programowania komputerów w ich obecnej sprzętowej postaci. Być
może w przyszłości inne komputery będą miały inne optymalne dla nich języki. Nie mam
z tym żadnego problemu.

> W jakimś sensie jest to wartościowy eksperyment dla tych, którzy
> potrafią się uczyć na cudzych błędach, bo wydaje mi się, że
> nie ma błędu, którego projektanci C++ by nie popełnili.

Nie ma też sukcesu, którego by nie odnieśli.

W tym kontekście C++ jest podobny do angielskiego.

Stroustrup powiedział: są dwa rodzaje języków - te, które wszyscy krytykują i te,
których nikt nie używa.

> Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój,

Mój stosunek do C++ jest pragmatyczny. Jestem inżynierem. :-)

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

do góry

W dniu piątek, 25 sierpnia 2017 01:12:43 UTC+2 użytkownik M.M. napisał:
> W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:
>
> > Zależy do czego. Rzecz z bibliotekami ma się tak,
> > że ich użyteczność ogranicza się zazwyczaj do celu,
> > w jakim zostały zrobione. Mówiąc inaczej, to są przetarte
> > szlaki, i do rozwiązania typowych problemów z reguły
> > pewnie wystarczą.
> No tak. Ale, o ile się nie mylę, podobnie jest w każdym języku.
> Część zadań rozwiązuje się przy pomocy środków jakie są
> dostarczane na poziomie języka, a drugą część na poziomie
> środków z bibliotek. Jeśli jest więcej na poziomie
> języka i język umożliwia bardziej zwartą składnię, to
> można odnieść wrażenie, że język jest lepszy do danego
> zadania. Lepszy w sensie że trzeba mniej kodu wpisać,
> zapewne jest. Poza tym to nie wiem... Napisałeś kilka
> postów powyżej, że niektóre języki nie są tylko językami
> programowania, ale językami myślenia. Jeśli się myśli
> algorytmami, to pewnie masz rację, chociaż... napiszę poniżej
> coś o pewnym programie do gry w szachy. Ale jeśli myśli się
> optymalnym rozwiązaniem danego problemu, to może język
> C++ jest językiem myślenia?

Nie wiem. Ja nie myślę algorytmami, tylko relacjami
między pojęciami. W moim odczuciu myślenie, którego
uczy C++, jest raczej dość kulawe, co bierze się stąd,
że jest w nim dużo niespójności i przypadkowych decyzji.
W rezultacie tego rodzaju wzorzec może podszeptywać
programistom, że "z niespójnościami da się żyć" i że
"przypadkowe decyzje są nie do uniknięcia". Nawet jeśli
z niespójnościami da się żyć, a przypadkowe decyzje są
nie do uniknięcia, wydaje mi się, że to nie jest dobra
nauka.

> > Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów,
> > to jak najbardziej korzystaj z niego.
> > Ale stąd jest jeszcze daleka droga do powiedzenia, że jest
> > "najlepszy",
> Bez kontekstu powiedzenie o czymś że jest najlepsze w ogóle
> nie ma sensu.

Zgadzam się.

> > tak jak niektóre osoby by chciały. Być może
> > w niektórych sytuacjach rzeczywiście będzie najlepszy,
> > ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym
> > -- bo akurat nikt nie zrobił lepszych bibliotek dla innych
> > języków. C++ jako abstrakcyjna notacja do komunikowania
> > i zapisywania idei raczej się nie nadaje.
> Pewnie że nie, bo do tego celu najlepszy jest metakod.

Nie znam takiego słowa. Może masz na myśli to, co określa
się mianem pseudokodu?

Ale skoro tak, to dlaczego ów "metakod" nie miałby być
językiem, który od razu można wykonać na komputerze?

> > Nie jest dobrym
> > narzędziem dla umysłu (choć może jest dobrym narzędziem
> > dla przemysłu)
> Może zależy jaki umysł? Jeśli umysł jest nastawiony na
> optymalizację kodu, to może jest dobrym językiem dla
> umysłu?

Wrócę do tego wątku mniej więcej za miesiąc, proszę
o cierpliwość :)

> > Z C++ jest taki problem, że to nie jest język, tylko
> > worek różnych ficzerów, które czasem do siebie pasują,
> > a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był
> > Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać
> > tak, jakby to było C, to też możesz. Niektórzy powiedzą,
> > że to dobrze, bo "język daje wolność". Jednak ja nie
> > uważam, że to jest dobra wolność, bo jeżeli masz w zespole
> > programistów z różnym backgroundem, to każdy będzie mógł
> > pisać po swojemu.
>
> Ja się wykłócałem i to w innych językach o sposób nazywania
> zmiennych, pól, metod i klas. I to nie o to że nazwa jest
> zbyt skrótowa i za mało mówi, czy zbyt rozwlekła i odciąga
> uwagę od istoty kodu, tylko o to, kiedy duża litera, kiedy
> znak podkreślenia. Każdy ma jakiś swój background. W zespole
> trzeba przyjąć jakieś zasady.

Jasne, zdecydowanie tak.
To jest też powód, dla którego cenię Pythona -- bo daje wskazówki
odnośnie tego, jak należy w nim programować. Z tego też względu
wolę Scheme'a, bo nie stawia dziwacznych ograniczeń na nazewnictwo
zmiennych.

> > Dla odmiany, wydaje mi się, że języki, które narzucają
> > na programistę więcej ograniczeń, jak np. Clojure, w którym
> > wszystko jest niemutowalne, w rezultacie dają kod dużo
> > lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej
> > prezentacji, której tytuł mówi już dość wiele: "Constraints
> > Liberate, Liberties Constrain":
> > https://www.youtube.com/watch?v=GqmsQeSzMdw
> Żałuję teraz że nie znam tego języka, byśmy porozmawiali.

Masz na myśli Scalę, czy angielski? :)
Jeżeli idzie o Scalę, to przyznam, że nie do końca rozumiem
fenomen, ale chyba zamysł był taki, żeby ułatwić programistom
Javy wejście w świat programowania funkcyjnego.

> > Pytanie, skąd się uczyłeś C++a
> Z literatury.

No jo. Tyle że książek jest dużo.
Jak wspominałem, ja się uczyłem z "Język C++" Stroustrupa.
To może nie być zbyt dobra książka do nauki.

> > I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć
> > świadomość, że to jest w dużej mierze owoc tego, co się im
> > jako firmie udało wyrzeźbić z tego kloca, jakim jest C++.
> > A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów.
> > Pytanie, ile te próby i błędy kosztowały.
>
> Ja się zgadzam, że C++, za wyjątkiem sytuacji gdy już są
> gotowe biblioteki, nie jest najlepszym języku do szybkiego
> wykonania aplikacji. Natomiast jak "rzeźbiłem z tego kloca"
> aplikację która obsługiwała bazę ram 1TB, to w C++ chociaż
> mogłem wyrzeźbić, a we wszelkich innych językach/narzędziach
> by padło przy 100GB, a może przy 20GB. W rozwiązaniu
> pilotażowym opartym o PHP + JS + PgSQL nawet nie ruszyło.

Nie wiem, czy we wszystkich. Myślę że Clojure albo Scala
mogłyby spokojnie pociągnąć. Kiedyś też zdarzało mi się przetwarzać
wielkie zbiory danych w Perlu, i radził sobie doskonale.

> > Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć
> > przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji.
> > Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia
> > optymalizujące.
> Mi też tak mówili wiele razy, wiele osób, w wielu sytuacjach.
> A potem narzędzi optymalizacyjnych nie było i dupa.

Zgadzam się, że to jest w praktyce wielki problem, dlatego
moim zdaniem powinniśmy się skupić na opracowywaniu tego rodzaju
narzędzi. Pewnie "linia najmniejszego oporu" przebiega przez ręczne
optymalizowanie aplikacji w C++, ale z punktu widzenia "rozwoju ludzkości"
bardziej racjonalne wydaje się wykonanie optymalizacji tylko raz
dla wszystkich programów, a nie tyle razy, ile jest programów.

Ale zgodzę się, że z dobrymi narzędziami jest taki problem,
że albo ich nie ma, albo nie wiemy o tym, że są.

> Pewnie że
> ja też bym chciał programować tylko w Javie, bo się zakochałem w
> tym języku. Gdy wydajność nie jest ważna, to powinno się sięgać
> po takie języki.

Nie rozumiem jak można się zakochać w Javie :)

> > To też jest problem, że jak chcesz mieć kontener, to musisz
> > wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu
> > nie da się rozwiązać, zachowując kompatybilność wsteczną.
> Gdy wydajność nie jest ważna, to się bierze pierwszy z
> brzegu i potem konwertuje, jeśli np. biblioteka gui nie
> akceptuje std::vector. Gdy jest ważna, to szablon się
> parametryzuje szablonem sparametryzowanym przez jeszcze trzy
> inne szablony i sprawdza każdy wariant - i mamy typową
> sieczkę optymalizacyjną, a nie kod podatny na refaktoryzację i
> rozwój.

To jest akurat najprostsza rzecz: jeżeli masz program w C++ korzystający
z STLowych kolekcji, to łatwo powinno być napisać np. algorytm genetyczny,
który zadany zbiór przypadków testowych bada na różnych konfiguracjach
kolekcji.


> > Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę
> > nad sprzętem, to dobra rzecz.
> > Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów
> > język może wiedzieć o systemie, na którym jest uruchamiany, tym
> > lepszą robotę mogą odwalić narzędzia uruchomieniowe.
> Taka jest teoria. W praktyce byśmy musieli mieć sztuczną inteligencję
> do kompilowania kodu w językach wysokiego poziomu. Kompilator
> musiałby wiedzieć jakiej puli algorytmów może użyć aby zapewnić
> poprawne wyjście dla wszystkich dozwolonych wejść.

Tak.


> > Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci?
> Dlatego że wierzę, że dla takiego języka i sposobu programowania
> jaki taki język pociąga za sobą, można w praktyce jeszcze napisać
> kompilator generujący bardzo efektywny kod. A programowanie byłoby
> wygodniejsze niż w C++.

Naprawdę, jedyne, co brak automatycznego zwalniania pamięci umożliwia,
to pisanie programów z wyciekami pamięci.

> > Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem.
> Ok.
>
> > Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie,
> > ale niestety powodowało to narzut złożoności algorytmicznej w stosunku
> > do wersji korzystających z mutacji.
> > Stąd teraz mam taką zabawę, że wymyślam metody automatycznej
> > transformacji programów napisanych funkcyjnie w wydajniejsze
> > programy stosujące mutację.
> Nie wiem co to jest mutacja. Jak to się zachowuje po optymalizacji,
> spadła złożoność algorytmiczna?

Mutacja, czyli modyfikacja istniejącego obiektu.
Na przykład takie coś, co wyszło w rozmowie z AK, w Pythonie:

a = [1,2,3]
b = [4,5,6]
a += b

w trzeciej linijce tablica "a" została zmodyfikowana, czy też
doszło do "mutacji". faktycznie może "mutacja" nie ma w języku polskim
najlepszej konotacji, ale często mówi się np. o obiektach albo zmiennych
niemutowalnych.

przykład, którym na razie się zajmowałem, to haskellowy wariant
quicksorta:

qsort [] = []
qsort (pivot:rest) = (qsort below) ++ [pivot] ++ (qsort above)
where below = [x | x <- rest, x < pivot]
above = [x | x <- rest, x >= pivot]

problem z tym, że ta funkcja nie jest "quick", i że -- tak jak
oryginalny Quicksort Hoare'a działał podstawiając elementy tablicy
w miejscu (czyli mutując tablicę), tak ten generuje bardzo dużo
śmieci. Ale istotę jego działania widać jak na dłoni.

> Jakby to działało, gdybyś od razu w C++ lub Javie napisał?

Za mniej więcej miesiąc podeślę, to będziesz mógł sam ocenić,
ale podejrzewam, że raczej bym czegoś takiego nie napisał w C++
ani w Javie

do góry

On Wed, 23 Aug 2017 22:02:42 +0200, "AK" <n...@n...net> wrote:
> PS: Nie. Nie FORTRAN. To okropny jezyk

I za to go lubię. Pisanie w Fortranie daje emocje nieporównywalnie z
niczym innym. No może Forth jeszcze, rep dup i takie tam.

W dodatku gdy napisze się coś w Fortranie, to jest 99% szansa że Seby
i Adrianki będą czuły się wykluczone z zabawy. A to też ma wartość.

do góry

On Fri, 25 Aug 2017 06:06:03 +0200, "AK" <n...@n...net> wrote:
> PS: / albo // cus uzywalo do konkatenacji. Chyba PL/1 jesli dobrze
pamietam
> albo jakas idiotyczna odmiana FORTRANu

Fortran

do góry

On Fri, 25 Aug 2017 06:04:57 +0200, "AK" <n...@n...net> wrote:
> Istnialy obok siebie i bylo super dopuki
> nie nastapil "wspanialy"
> C++ i nie "ujednolicil" przypisania do =

Primo, pojedynczy znak równości to notacja przypisania także w C,
które było /trochę/ wcześniej.

Secundo, pierwotna notacja z let w Basic została wsparta przez
uproszczoną bez let. I to też nastąpiło znacznie wcześniej niż C++.

Tertio, Fortran też używa od zawsze znaku równości jako postawienia.
Tak samo Snobol.

do góry

On Wed, 23 Aug 2017 22:35:38 +0200, "AK" <n...@n...net> wrote:
> Slawek ma racje. To "nowomowa".
> Oryginalnie byla tylko rekursja

Sam już nie wiem: SJP obecny zna rekurencję, nie zna rekursji.

> Oryginalnie bylo tylko FORTRANu i Algolu a nie "dzisiejsze"
Fortrana , Algola
> itp itd

Też zaczynałem wątpić. Zajrzałem do odpowiednio starych podręczników:
jest Fortran, Fortranu.

Jeszcze dla przypomnienia: Linux, Linuksa.

Kłopoty są z Basic. Bo nazwa Basica wygląda jak odmiana przez
przypadek, a w istocie to w mianowniku nazwa dialektu języka Basic.

do góry

On Thu, 24 Aug 2017 20:11:43 +0200, Mateusz Bogusz <m...@o...pl>
wrote:
> A w języku Wolfram napiszę web serwis z api po http? A aplikację
> desktopową? A skrypt systemowy co mi z sysloga wyciągnie i
przeparsuje
> dane, po czym wyśle stosownego maila?

3 x TAK

Co do serwisu to obejrzyj sobie Wolfram Alpha.

Dodam: da się używać z Arduino. I jeszcze (była?) darmowa Mathematica
dla Rasberry Pi.

do góry

W dniu piątek, 25 sierpnia 2017 11:35:46 UTC+2 użytkownik g...@g...com
napisał:
> W dniu piątek, 25 sierpnia 2017 01:12:43 UTC+2 użytkownik M.M. napisał:
> > C++ jest językiem myślenia?
>
> Nie wiem. Ja nie myślę algorytmami, tylko relacjami
> między pojęciami. W moim odczuciu myślenie, którego
> uczy C++, jest raczej dość kulawe, co bierze się stąd,


ja ostatnio piszac w c zauwazylem ze umiem kodowac nie myslac - nawet nad tym nad
czym wydawaloby sie trzeba pomyslec by to zrobic - ale to moze zasluga ojej
biblioteki sicl ktra jest naprawde dobra (o tym pozniej)

zamiast myslec robie tabelke robie pentelke robie switcha (drzewko ifow) i dziala -
myslania zaoszczedzono co jest dobre bo myslenie jest ciekawe ale też
męczy (i to czasem nielekko)

wiecej o siclu (blessing of the sicl) chyba pozniej

do góry