[siepet]

co ciekawsze? #python czy #ruby?

[applicative_functor]

@siepet: A do czego?

[siepet]

@applicative_functor: tak strasznie ogólnie pytam.

[AgresywnyKaloryfer]

@siepet: Wonsz pytong ma prostszą składnię.

[applicative_functor]

@siepet: ruby to praktycznie tylko ror (ruby on rails - framework webowy), python ma o wiele większe spektrum zastosowań.

[KrzychuBanan]

@siepet: c++

[p.....l]

@siepet: pyton

[krzyzakp]

@siepet: python ;) Duzo wiecej zastosowan, wiecej pracy w nim (chocby django - czyli wframework webowy jak pisano wyzej) i cala masa innych przeznaczen.. A Ruby to tylko RoR + puppet z tego co sie spotkalem z tym jezykiem...

[Hauleth]

@applicative_functor: @krzyzakp: Gówno prawda:

- Rake (wiele projektów JSowych używa tego do konkatenacji kodu)

- Guard (obserwowanie zmian w plikach i odpowiednie reagowanie na to, aktualnie jedyna metoda by uruchomić LiveReload na Linuksie)

- Sass/SCSS (jeden z najpopularniejszych preprocesorów CSS)

- Sinatra (dużo lżejszy i mniej skomplikowany framework do web)

- Faye (na razie implementacje tylko w Rubym i Node)

- Vagrant (superpotężne narzędzie do zarządzania maszynami wirtualnymi w projekcie)

[p.....y]

@applicative_functor: @krzyzakp: nie zgadzam się z wami, w ruby napisano sporo ciekawych narzędzi - chociażby foreman, sass, rerun czy localtunnel, a co do frameworków jest jeszcze chociażby sinatra.

@siepet: zdecydowanie python, nie dość że ma dużo szersze spektrum zastosowań i dużo bardziej czytelną składnię (+ pep8), to powstało w nim jeszcze więcej użytecznych narzędzi i bibliotek niż w ruby :)

[applicative_functor]

@Hauleth: @paffnucy:

Ok, ok, ja tego nie neguję. Pisałem bardziej pod kątem "co potem można robić w pracy jak się nauczy danego języka". A tutaj niestety ruby dużo więcej nie oferuje.

[Hauleth]

@siepet: Ja się wyłamię i powiem Ruby. Pytasz o ciekawość, a nie spektrum zastosowań. Natomiast Ruby jest bardzo plastycznym językiem, dzięki czemu łatwo jest tworzyć własne DSLe, poznasz ideę domknięć, symboli. Dużo prościej IMHO tworzy się narzędzia CLI (przy zastosowaniu Thora czy Rake).

Z tą czytelnością też się nie zgodzę. Do Rubiego masz https://github.com/bbatsov/ruby-style-guide. Ogólnie ostatnio napisałem wpis na blogu, nt. off-side rule w programowaniu http://lukasz.niemier.pl/post/54984282328/off-side-rule i uważam, że składnia poprzez

[siepet]

@Hauleth: dzięki za obszerniejszą wypowiedź, mi natomiast podoba się styl wcięć w pythonie, ale to plus i minus jednocześnie moim zdaniem, ale przynajmniej kod jest przejrzysty od samego początku.

[Hauleth]

@siepet: Jeśli ktoś nie stosuje wcięć to jest dupa a nie programista, wymuszanie tego na poziomie składni jest IMHO bez sensu. Dodatkowo pojawia się wtedy problem tab vs space, wystarczy że zatrudni się jedną osobę, która zapomni ustawić tak jak ustalono i wszystko #!$%@?. Dodatkowo ja czasem nie mam czasu by powstawiać wcięcia, lub np. wklejam fragment kodu z internetu. Jeśli wtedy rozjadą Ci się wcięcia to w Pythonie jesteś usmażony.

[Kiro]

Jeśli ktoś nie stosuje wcięć to jest dupa a nie programista, wymuszanie tego na poziomie składni jest IMHO bez sensu. Dodatkowo pojawia się wtedy problem tab vs space, wystarczy że zatrudni się jedną osobę, która zapomni ustawić tak jak ustalono i wszystko #!$%@?. Dodatkowo ja czasem nie mam czasu by powstawiać wcięcia, lub np. wklejam fragment kodu z internetu. Jeśli wtedy rozjadą Ci się wcięcia to w Pythonie jesteś usmażony. Natomiast w

[Hauleth]

@Kiro: Co do wklejania to żadne znane mi IDE nie zna twoich intencji, więc skopiowanie kodu (Python)

for i in range(1,n)

  f(i)

do kodu

def f(n):

  print(n)

# w tym miejscu

nie zawsze da jednoznaczny wynik. Co do styleguide to Ruby ma podaną przeze mnie wcześniej zrobioną przez Bozhidara Batsova wersję, która jest rozwijana przez społeczność, która jak na moje jest dużo bardziej jednorodna i zgodna co do stosowanych praktyk niż

[Kiro]

@Hauleth: Kopiowanie (ba, samo publikowanie) kodu bez wcięć mija się z celem. Co do wklejania - każde porządne IDE ogarnie że skoro wklejasz bezpośrednio pod

def f(n)

to chcesz mieć o jeden tab dalej. .Jeśli przed i po miejscu w które wklejasz są 2 wcięcia, to wiadomo że chcesz na drugim wcięciu. W 99% przypadków wywnioskowanie o ile wklejany kod powinien być wcięty w stosunku do reszty jest banalne, gorzej gdy

[Hauleth]

@Kiro: Jak byś nie zauważył, ja nie mówiłem o kopiowaniu kodu bez wcięć, mówiłem o tym, że wcięcia mają tendencję do rozjeżdżania się przy wklejaniu. Poza tym nie używam IDE tylko Vima, gdzie masz 2 opcje (

p

i

gp

), ale nie zmienia to mojego pogardliwego stosunku do języków programowania, które wymagają off-side rule (no może z 2 wyjątkami,

Makefile

i (częściowo) Haskell). Uważam, że ta zasada działa tylko w

[Kiro]

Jak byś nie zauważył, ja nie mówiłem o kopiowaniu kodu bez wcięć, mówiłem o tym, że wcięcia mają tendencję do rozjeżdżania się przy wklejaniu.

@Hauleth: Do tego nawiązałem na początku, jak ktoś na stronę nie wkleił bez wcięć to wklejając do IDE nic się nie ma prawa rozjechać, nie ważne czy stosujesz 2/4/8 spacji czy taby. W drugim komentarzu pisałeś już o wklejaniu w odpowiednie miejsce w bloku to do tego

[bliss]

idiotyczna idea nazwanych argumentów w Rubym

@Hauleth: mógłbyś rozwinąć myśl? dlaczego sądzisz że jest to idiotyczna idea?

[Hauleth]

@bliss: ko nie wiem co za imbecyl wymyślił by zrobić do tego nową składnię, zamiast po człowieczemu użyć gotowej, tylko dorobić nowy sposób przypisywania argumentów (jak jest w R). Czyli zamiast pisać:

def foo(a: 'boo', b: 'goo')

  ...

end

pisać po staremu

def foo(a = 'boo', b = 'goo)

  ...

end

W ten sposób rozwijamy składnię, a nie ją rozszerzamy.