-
31. Data: 2017-08-08 21:52:30
Temat: Re: Rust
Od: "M.M." <m...@g...com>
On Tuesday, August 8, 2017 at 7:57:49 PM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> > Nie chodzi o to że się nie da, tylko jaki sens? Język interpretowany
> > bez możliwości wywołania funkcji po nazwie
>
> Przepraszam. Co Ty pieprzysz ?
> W interpretowanym C masz wszystko "na patelni".
> Po nazwie _głównie_ !
Ostatnio było tutaj o rozmowie podobnej do gry w szachy z gołębiem...
-
32. Data: 2017-08-08 22:14:32
Temat: Re: Rust
Od: slawek <f...@f...com>
On Tue, 8 Aug 2017 20:13:33 +0200, "AK" <n...@n...net> wrote:
> Ten podzial na kompilowane/interpretowane
> pielegnują z uporem godnym lepszej sprawy
I właśnie o to chodzi. Ktoś kiedyś gdzieś... i teraz ciągle
powtarzane jest ten nonsens. Pięknym przykładem jest Basic: są
interpretery, są kompilatory (do natywnego), są kompilatory skrośne
(Bascom), są JIT i co tam tylko (Visual, VBA). Że Basic jest do
niczego bo interpretowany po raz pierwszy usłyszałem gdzieś tak w
1972. Nawet jeżeli była to prawda (wtedy) to trochę się zmieniło
przez te pół wieku. Podział kompilowane/niekompilowane dziś nie ma
sensu. Zwłaszcza że można pisać ze sprawdzaniem składni, używać
różnych narzędzi podobnych do lint itd. Z drugiej strony na 99%
kompilator nie wykryje np. skasowania linijki gdzieś ze środka
programu, takiej jak np. x = x + a.
-
33. Data: 2017-08-08 22:34:31
Temat: Re: Rust
Od: "M.M." <m...@g...com>
On Tuesday, August 8, 2017 at 10:14:36 PM UTC+2, slawek wrote:
> On Tue, 8 Aug 2017 20:13:33 +0200, "AK" <n...@n...net> wrote:
> > Ten podzial na kompilowane/interpretowane
> > pielegnują z uporem godnym lepszej sprawy
>
> I właśnie o to chodzi. Ktoś kiedyś gdzieś... i teraz ciągle
> powtarzane jest ten nonsens. Pięknym przykładem jest Basic: są
> interpretery, są kompilatory (do natywnego), są kompilatory skrośne
> (Bascom), są JIT i co tam tylko (Visual, VBA).
Racja, są.
> Że Basic jest do
> niczego bo interpretowany po raz pierwszy usłyszałem gdzieś tak w
> 1972.
Moim zdaniem to prawda, był zdecydowanie za mało elastyczny jak
na język interpretowany. Już sam fakt, że jeden język można
skompilować (ale uczciwie skompilować na instrukcje procesora, a
nie wcielać do pliku binarnego połowę interpretera) i interpretować,
jest podejrzany.
> Nawet jeżeli była to prawda (wtedy) to trochę się zmieniło
> przez te pół wieku. Podział kompilowane/niekompilowane dziś nie ma
> sensu.
Bez określenia celu nic nie ma sensu.
> Zwłaszcza że można pisać ze sprawdzaniem składni, używać
> różnych narzędzi podobnych do lint itd. Z drugiej strony na 99%
> kompilator nie wykryje np. skasowania linijki gdzieś ze środka
> programu, takiej jak np. x = x + a.
To racja.
-
34. Data: 2017-08-09 07:23:47
Temat: Re: Rust
Od: slawek <f...@f...com>
On Tue, 8 Aug 2017 13:34:31 -0700 (PDT), "M.M." <m...@g...com>
wrote:
> Moim zdaniem to prawda,
> był zdecydowanie za mało elastyczny jak
> na język interpretowany.
Co rozumiesz przez "elastyczność"?
I jaki Basic? Ten z początków lat 70-tych, ten z ZX81, Basica,...,
obecny Visual?
-
35. Data: 2017-08-09 14:43:45
Temat: Re: Rust
Od: "M.M." <m...@g...com>
On Wednesday, August 9, 2017 at 7:24:13 AM UTC+2, slawek wrote:
> On Tue, 8 Aug 2017 13:34:31 -0700 (PDT), "M.M." <m...@g...com>
> wrote:
> > Moim zdaniem to prawda,
> > był zdecydowanie za mało elastyczny jak
> > na język interpretowany.
>
> Co rozumiesz przez "elastyczność"?
>
> I jaki Basic? Ten z początków lat 70-tych, ten z ZX81, Basica,...,
> obecny Visual?
Inny język nadaje się do kompilowania na natywny kod procesora, inny do
interpretowania. Interpreter generalnie może więcej niż procesor,
interpreter będzie zawsze nadzbiorem możliwości procesora. Po co
wskaźniki w języku interpretowanym? Dlaczego nie można funkcji wywołać
poprzez nazwę umieszczoną w zmiennej w języku interpretowanym?
Pozdrawiam
-
36. Data: 2017-08-09 15:50:13
Temat: Re: Rust
Od: Adam M <a...@m...com>
On Saturday, August 5, 2017 at 12:10:28 PM UTC-4, Borneq wrote:
> Jakie jest wasze zdanie na temat tego języka?
> Bardzo ciekawy, brakowało mi graficznego UI, ale jest teraz relm i conrod:
> http://relm.ml/relm-intro
> https://github.com/PistonDevelopers/conrod
>
> Czytałem że nie używa odśmiecania jak Go ale zupełnie inny sposób radzi
> sobie z wyciekami pamięci.
IMHO to język ktory szuka problemów do rozwiązania - prawdopodobie zostanie niszowym
językiem podobnie jak Ada z tym że Ada ma za sobą lata rozwoju i solidne biblioteki.
Nie oferuje nic doswiadczonym programistom w C/C++ a zmusza ich nauczenia się
manieryzmów języka. Programiści wysokopoziomowych języków nawet nie zainteresuja sie
takim czymś bo i po co im to. Jedną z najwiekszych słabości Rusta są fatalnej jakości
biblioteki (lata mina kiedy te biblioteki osiagną jakość bibliotek dla C i C++).
Drugim problemem jest podejście całego środowiska otaczjacego Rust - wygląda to na
podejście: my jesteśmy tymi którzy posiedli prawdę i biada tym którzy sie z nami nie
zgadzają.
Adam M.
-
37. Data: 2017-08-09 16:38:42
Temat: Re: Rust
Od: slawek <f...@f...com>
On Wed, 9 Aug 2017 05:43:45 -0700 (PDT), "M.M." <m...@g...com>
wrote:
> Inny język nadaje się do kompilowania na natywny kod procesora, i=
> nny do
> interpretowania.
To jest twoja opinia. Nie poparta faktami. Bardzo nieprecyzyjnie
wyrażona.
Sorry, ale nie tylko że nie przekonałeś mnie... lecz także ujawniłeś
swój poziom wiedzy, tak że dalsze twoje "objawienia" będę traktował
tak jak na to zapewne zasługują.
> Interpreter generalnie może więcej niż proc=
> esor,
> interpreter będzie zawsze nadzbiorem możliwości procesora.
Kolejne "objawienie". Nota bene, wiele CPU ma rozkaz xchg, którego
nie ma np. w C.
> Po co
> wskaźniki w języku interpretowanym? Dlaczego nie można funkc=
> ji wywołać
> poprzez nazwę umieszczoną w zmiennej w języku interpretowany=
> m?
A po co są rowery? Nie używam, więc po co? Zabronić produkcji rowerów
i używania wskaźników!
Na szczęście jesteś wielkim nikim. Bo gdy ludzie (?) o twojej
mentalności dorwą się do władzy, to każdy o poziomie IQ > 50 jest ich
wrogiem. Nie tolerują niczego co nie jest dla nich bezpośrednio
potrzebne i czego intelektualnie nie ogarniają.
-
38. Data: 2017-08-09 16:48:49
Temat: Re: Rust
Od: Adam M <a...@m...com>
On Wednesday, August 9, 2017 at 10:38:46 AM UTC-4, slawek wrote:
> On Wed, 9 Aug 2017 05:43:45 -0700 (PDT), "M.M." <m...@g...com>
> wrote:
> > Inny język nadaje się do kompilowania na natywny kod procesora, i=
> > nny do
> > interpretowania.
>
>
> To jest twoja opinia. Nie poparta faktami. Bardzo nieprecyzyjnie
> wyrażona.
>
> Sorry, ale nie tylko że nie przekonałeś mnie... lecz także ujawniłeś
> swój poziom wiedzy, tak że dalsze twoje "objawienia" będę traktował
> tak jak na to zapewne zasługują.
>
> > Interpreter generalnie może więcej niż proc=
> > esor,
> > interpreter będzie zawsze nadzbiorem możliwości procesora.
>
> Kolejne "objawienie". Nota bene, wiele CPU ma rozkaz xchg, którego
> nie ma np. w C.
>
>
Z całym szacunkiem ale to już szanownego kolegę poniosło - język C potrzebuje rozkazu
xchg jak łysy grzebienia - kompilator może uzyć rozkazu xchg w trakcie kompilacji
kodu w C do jezyka mszynowego (lub programista może zrobić wstawke asemblerowa w
kodzie C) ale normalnie to jest o jeden poziom za nisko dla C.
Adam M
<ciach/>
-
39. Data: 2017-08-09 17:00:40
Temat: Re: Rust
Od: slawek <f...@f...com>
On Wed, 9 Aug 2017 07:48:49 -0700 (PDT), Adam M
<a...@m...com> wrote:
> język C potrzebuje rozkazu xchg jak łysy grzebienia
Doceniam dowcip. I widzę że niewiele wiesz o programowaniu w C.
-
40. Data: 2017-08-09 18:42:40
Temat: Re: Rust
Od: "M.M." <m...@g...com>
On Wednesday, August 9, 2017 at 4:38:46 PM UTC+2, slawek wrote:
> On Wed, 9 Aug 2017 05:43:45 -0700 (PDT), "M.M." <m...@g...com>
> wrote:
> > Inny język nadaje się do kompilowania na natywny kod procesora, i=
> > nny do
> > interpretowania.
>
>
> To jest twoja opinia. Nie poparta faktami. Bardzo nieprecyzyjnie
> wyrażona.
Niby nie poparta faktami, a żadnego kontrprzykładu nie podałeś.
> Sorry, ale nie tylko że nie przekonałeś mnie... lecz także ujawniłeś
> swój poziom wiedzy, tak że dalsze twoje "objawienia" będę traktował
> tak jak na to zapewne zasługują.
Tak każdy bez żadnej wiedzy może napisać.
> > Interpreter generalnie może więcej niż proc=
> > esor,
> > interpreter będzie zawsze nadzbiorem możliwości procesora.
>
> Kolejne "objawienie". Nota bene, wiele CPU ma rozkaz xchg, którego
> nie ma np. w C.
Sprowadzasz rozmowę na inny temat. Zawsze było tak, że im język był
wyższego poziomu, tym więcej robiła jakaś maszyna wirtualna lub
jakieś biblioteka, bo skompilowanie tego na instrukcje maszynowe
byłoby skrajnie trudne i nonsensowne.
> > Po co
> > wskaźniki w języku interpretowanym? Dlaczego nie można funkc=
> > ji wywołać
> > poprzez nazwę umieszczoną w zmiennej w języku interpretowany=
> > m?
>
>
> A po co są rowery? Nie używam, więc po co? Zabronić produkcji rowerów
> i używania wskaźników!
A co mają rowery wspólnego z językami programowania? Dlaczego nie
podasz kontrprzykładu który ma coś wspólnego z językami programowania?
Jak to w ogóle zrozumiałeś ( tamtego kontekstu ) gdy pytałem po
co wskaźniki w języku interpretowanym?
> Na szczęście jesteś wielkim nikim. Bo gdy ludzie (?) o twojej
> mentalności dorwą się do władzy, to każdy o poziomie IQ > 50 jest ich
> wrogiem. Nie tolerują niczego co nie jest dla nich bezpośrednio
> potrzebne i czego intelektualnie nie ogarniają.
Ale jaja :D