Ah ten ruby...
Piotr L.
O co chodzi z tym Ruby? sledze od czasu do czasu wiesci ze swiata tego
jezyka, i odnosze wrazenie, ze jest go wiecej i wiecej, dynamika
spolecznosci ruby tez jakby wieksza, mimo ze python jest starszy.
Skad takie zainteresowanie tym jezykiem? czy to Ruby on rails dzwignal go
do takiej popularnosci? Na oko tak, ale w takim razie czemu python nie
dorobil sie podobnego czegos?
Powiadaja, ze python mimo wszystko ma ladnieszja, prostsza, logiczniejsza
itd skladnie. W takim razie czemu to w ruby powstal RoR? Moze po prostu
dlatego, ze w nim sie pisze latwiej, szybciej mimo ze moze nie tak
elegancko (czy jakkolwiek to nazwiemy)?
Czy do pythona wyszla dobra ksiazka o nim? Dobra, tzn nie taka, ktora
tylko opisuje jezyk, ale taka ktora pisze jak w nim efektywnie pisac
programy? Ruby mam wrazenie, ze takowe ma, i to nie tylko dobre ale nawet
okreslone jako wybitne (Agile web development...).
Czyzby ruby mial okazje zrobic to co python, tylko lepiej - tzn stac sie
popularnym jezykiem o ktorym duzo i wszedzie sie gada no i uzywa?
Pozdrawiam
P.
Jaroslaw Zabiello
> O co chodzi z tym Ruby? sledze od czasu do czasu wiesci ze swiata tego
> jezyka, i odnosze wrazenie, ze jest go wiecej i wiecej, dynamika
> spolecznosci ruby tez jakby wieksza, mimo ze python jest starszy.
Co do dynamiki społeczności (zwłaszcza w PL) to prawda. Co chwilę ktoś
organizuje jakieś spotkania. Ostatnio ruszyło się troszkę z Pythonem i
powstają inicjatywy wspólne Ruby+Python (lub Rails i Django).
> Skad takie zainteresowanie tym jezykiem? czy to Ruby on rails dzwignal go
> do takiej popularnosci? Na oko tak, ale w takim razie czemu python nie
> dorobil sie podobnego czegos?
Python trochę przespał swój czas. Ruby wystrzelił na fali zainteresowania
Railsami. Ja np. zainteresowałem sie wpierw Railsami, potem Rubim. Zresztą
do dziś marketing w środowisku Pythona leży i kwiczy. Chyba tylko
TurboGears się jakoś stara. No może trochę Django. Ale Pylons? Zope?
Tragedia. Zupełny brak wyczucia i umiejętności promowania produktu.
Dokumentacja albo w strzępach, albo porozrzucana po całym internecie.
> Powiadaja, ze python mimo wszystko ma ladnieszja, prostsza, logiczniejsza
> itd skladnie.
Z tym akurat jest różnie. Wiele osób uważa, że składnia Rubiego jest
ładniejsza. Opinie są podzielone. Np. uważa się że model obiektowy Rubiego
jest bardziej elegancki i konsekwentny. Python jest językiem hybrydowym:
funkcyjno-obiektowym. Ruby jest językiem czysto obiektowym.
> W takim razie czemu to w ruby powstal RoR?
Bo jak przyjrzysz się RoR to zauważysz, że nie byłoby możliwe napisanie go
w Pythonie. RoR korzysta nie tyle z Rubiego co z modyfikowanej jego wersji,
zoptymalizowanej na użytek RoR. Np. przyjrzyj się helperom w RoR. Dzięki
temu, że Ruby pozwala na otwarcie i zmianę dowolnego obiektu możliwe są
takie zagrania jak: puts 123.kilobytes + 4.megabytes (RoR wzbogacił obiekty
które w Pythonie są nie do ruszenia). Także opcjonalne upuszczanie nawiasów
powoduje, że RoR wygląda bardzo ładnie:
class Book < ActiveRecord::Base
belongs_to :publisher
has_many: reviews
end
> Moze po prostu dlatego, ze w nim sie pisze latwiej, szybciej mimo ze
> moze nie tak elegancko (czy jakkolwiek to nazwiemy)?
Raczej odwrotnie. Pisze się wolniej, ale bardziej elegancko niż w Pythonie.
Wolniej, bo w Ruby masz wielokrotnie więcej metod dla każdego obiektu i
zapamietanie ich wszystkich jest znacznie trudniejsze. Wolniej, bo Ruby
jest bardziej "magiczny", mniej widać co i skąd się wzięło. Python jest
bardziej jawny, łatwiej zlokalizować co i skąd się bierze. No i ma mniej
metod, struktur pętli, warunków itp. Słowem: Python ma prostsza składnię i
łatwiej, szybciej można go opanować. Zwłaszcza że praktycznie każdy edytor
do Pythona rozwija także podpowiedzi na bazie wszechobecnych jego
docstringów (Ruby nie ma docstringów).
> Czy do pythona wyszla dobra ksiazka o nim? Dobra, tzn nie taka, ktora
> tylko opisuje jezyk, ale taka ktora pisze jak w nim efektywnie pisac
> programy? Ruby mam wrazenie, ze takowe ma, i to nie tylko dobre ale nawet
> okreslone jako wybitne (Agile web development...).
Chyba nie ma. Wiele osób narzeka też na słabą jakość dokumentacji Pythona.
Niektórzy (np. Cheetah) z lenistwa nawet nie tworzą dokumentacji, ale
odsyłają do... docstringów w kodzie źrółowym. Istny obciach.
> Czyzby ruby mial okazje zrobic to co python, tylko lepiej - tzn stac sie
> popularnym jezykiem o ktorym duzo i wszedzie sie gada no i uzywa?
Czas pokaże. Python jest za dobrym językiem aby tak dał się odsunąć w cień.
Ma silną pozycję w Google (głównie na nim bazują) i od jakiegoś czasu nawet
w Microsofcie (za sprawą IronPythona).
Na pewno nie nie stałoby się nic złego jakby ktoś napisał jakąś dobrą
książkę o Pythonie i o paru jego frameworkach. Do Django właśnie jedna
książka powstaje (jest dostępna online). Do TurboGears już napisano. Do
Pylons nic nie ma, a szkoda, bo to bardzo dobry framework. Do Plone i Zope
coś jest, ale nic w jęz. polskim. Poza tym Zope/Plone to inna bajka. Nie
można porównywać z lekkim RoR. Prędzej Django, Pylons czy TurboGears.
--
Jarosław Zabiełło
http://blog.zabiello.com
Jaroslaw Zabiello
> O co chodzi z tym Ruby? sledze od czasu do czasu wiesci ze swiata tego
> jezyka, i odnosze wrazenie, ze jest go wiecej i wiecej, dynamika
> spolecznosci ruby tez jakby wieksza, mimo ze python jest starszy.
Co do dynamiki społeczności (zwłaszcza w PL) to prawda. Co chwilę ktoś
organizuje jakieś spotkania. Ostatnio ruszyło się troszkę z Pythonem i
powstają inicjatywy wspólne Ruby+Python (lub Rails i Django).
> Skad takie zainteresowanie tym jezykiem? czy to Ruby on rails dzwignal go
> do takiej popularnosci? Na oko tak, ale w takim razie czemu python nie
> dorobil sie podobnego czegos?
Python trochę przespał swój czas. Ruby wystrzelił na fali zainteresowania
Railsami. Ja np. zainteresowałem sie wpierw Railsami, potem Rubim. Zresztą
do dziś marketing w środowisku Pythona leży i kwiczy. Chyba tylko
TurboGears się jakoś stara. No może trochę Django. Ale Pylons? Zope?
Tragedia. Zupełny brak wyczucia i umiejętności promowania produktu.
Dokumentacja albo w strzępach, albo porozrzucana po całym internecie.
> Powiadaja, ze python mimo wszystko ma ladnieszja, prostsza, logiczniejsza
> itd skladnie.
Z tym akurat jest różnie. Wiele osób uważa, że składnia Rubiego jest
ładniejsza. Opinie są podzielone. Np. uważa się że model obiektowy Rubiego
jest bardziej elegancki i konsekwentny. Python jest językiem hybrydowym:
funkcyjno-obiektowym. Ruby jest językiem czysto obiektowym.
> W takim razie czemu to w ruby powstal RoR?
Bo jak przyjrzysz się RoR to zauważysz, że nie byłoby możliwe napisanie go
w Pythonie. RoR korzysta nie tyle z Rubiego co z modyfikowanej jego wersji,
zoptymalizowanej na użytek RoR. Np. przyjrzyj się helperom w RoR. Dzięki
temu, że Ruby pozwala na otwarcie i zmianę dowolnego obiektu możliwe są
takie zagrania jak: puts 123.kilobytes + 4.megabytes (RoR wzbogacił obiekty
które w Pythonie są nie do ruszenia). Także opcjonalne upuszczanie nawiasów
powoduje, że RoR wygląda bardzo ładnie:
class Book < ActiveRecord::Base
belongs_to :publisher
has_many :reviews
end
> Moze po prostu dlatego, ze w nim sie pisze latwiej, szybciej mimo ze
> moze nie tak elegancko (czy jakkolwiek to nazwiemy)?
Raczej odwrotnie. Pisze się wolniej, ale bardziej elegancko niż w Pythonie.
Wolniej, bo w Ruby masz wielokrotnie więcej metod dla każdego obiektu i
zapamietanie ich wszystkich jest znacznie trudniejsze. Wolniej, bo Ruby
jest bardziej "magiczny", mniej widać co i skąd się wzięło. Python jest
bardziej jawny, łatwiej zlokalizować co i skąd się bierze. No i ma mniej
metod, struktur pętli, warunków itp. Słowem: Python ma prostsza składnię i
łatwiej, szybciej można go opanować. Zwłaszcza że praktycznie każdy edytor
do Pythona rozwija także podpowiedzi na bazie wszechobecnych jego
docstringów (Ruby nie ma docstringów).
> Czy do pythona wyszla dobra ksiazka o nim? Dobra, tzn nie taka, ktora
> tylko opisuje jezyk, ale taka ktora pisze jak w nim efektywnie pisac
> programy? Ruby mam wrazenie, ze takowe ma, i to nie tylko dobre ale nawet
> okreslone jako wybitne (Agile web development...).
Chyba nie ma. Wiele osób narzeka też na słabą jakość dokumentacji Pythona.
Niektórzy (np. Cheetah) z lenistwa nawet nie tworzą dokumentacji, ale
odsyłają do... docstringów w kodzie źrółowym. Istny obciach.
> Czyzby ruby mial okazje zrobic to co python, tylko lepiej - tzn stac sie
> popularnym jezykiem o ktorym duzo i wszedzie sie gada no i uzywa?
Czas pokaże. Python jest za dobrym językiem aby tak dał się odsunąć w cień.
Janusz A. Urbanowicz
> Heja
>
> O co chodzi z tym Ruby? sledze od czasu do czasu wiesci ze swiata tego
> jezyka, i odnosze wrazenie, ze jest go wiecej i wiecej, dynamika
> spolecznosci ruby tez jakby wieksza, mimo ze python jest starszy.
dla sporej częsci control-freaków nie do przyjęcia jest znaczące
formatowanie kodu
> Skad takie zainteresowanie tym jezykiem? czy to Ruby on rails dzwignal go
> do takiej popularnosci? Na oko tak, ale w takim razie czemu python nie
> dorobil sie podobnego czegos?
zope, django
> Powiadaja, ze python mimo wszystko ma ladnieszja, prostsza, logiczniejsza
> itd skladnie. W takim razie czemu to w ruby powstal RoR? Moze po prostu
> dlatego, ze w nim sie pisze latwiej, szybciej mimo ze moze nie tak
> elegancko (czy jakkolwiek to nazwiemy)?
patrz wyżej i ostatnie wątki o tabach
> Czy do pythona wyszla dobra ksiazka o nim? Dobra, tzn nie taka, ktora
> tylko opisuje jezyk, ale taka ktora pisze jak w nim efektywnie pisac
> programy? Ruby mam wrazenie, ze takowe ma, i to nie tylko dobre ale nawet
> okreslone jako wybitne (Agile web development...).
dive into python
*ziew* jedyne co jest interesujące w robieniu serwisów webowych to
kasa jaką można na tym w tej chwili zrobić
> Czyzby ruby mial okazje zrobic to co python, tylko lepiej - tzn stac sie
> popularnym jezykiem o ktorym duzo i wszedzie sie gada no i uzywa?
nie sądze, poza rails nie ma w zasadzie popularnych aplikacji
napisanych w rubym, w pythonie są, a web development to malutki
wycinek zastosowań języków programowania
--
JID: al...@hell.pl
PGP: 0x46399138
od zwracania uwagi na detale są lekarze, adwokaci, programiści i zegarmistrze
-- Czerski
climbus
> Na pewno nie nie stałoby się nic złego jakby ktoś napisał jakąś dobrą
> książkę o Pythonie i o paru jego frameworkach. Do Django właśnie jedna
> książka powstaje (jest dostępna online). Do TurboGears już napisano. Do
> Pylons nic nie ma, a szkoda, bo to bardzo dobry framework.
Było by skrajnie nieodpowiedzialnie pisać książkę o frmaeworku, który
nie ma jeszcze wersji 1.0 i się co chwilę zmienia. Wiele spraw jest
jeszcze nierozwiązanych, niedopracowanych. W przypadku Pylonsa każda
książka w momencie druku była by nieaktualna.
Climbus
Jaroslaw Zabiello
> dla sporej częsci control-freaków nie do przyjęcia jest znaczące
> formatowanie kodu
Zdedycydowanie przesadzasz. Co jak co, ale wcięcia w Pythonie nie mają
znaczenia. Jest przecież sporo pythonistów którzy przeszli na Rubiego.
Popularność Rubiego rozpętały Railsy. Teraz już jednak to idzie efekt kuli
śnieżnej. Ruby doskonale wykorzystał moment pędu jaki nadał mu RoR. Ludzie
zaczynają teraz doceniać Ruby dla samego języka, a nie dla Railsów. Python
nigdy nie posiadał swojej killer application połączonej z dobrą promocją
która by spowodowała podobny efekt kuli śnieżnej. Teraz jest chyba już za
późno. Najlepiej aby taka aplikacja pojawiła się wraz z informacjami o
języku. Python już jest znany od dawna. I być już teraz trochę za późno aby
jakoś lawinowo zdobywał większą popularność. Będzie ją nadal zdobywał, ale
wolniej, mniej gwałtownie. Ruby może odebrać Pythonowi część rynku. Na
pewno Railsy już odbierają go pehapowi.
> zope, django
Zope to zły przykład. Beznadziejna od początku promocja i dokumentacja.
Poza tym Zope2 jest krytykowany za wiele rzeczy, np. namieszane API. Zope3
to zmienia. Ale znowu: leży jego promocja i dokumentacja. Poza tym Zope to
inna klasa zastosowań. Co innego Django. Ale z kolei Django to relatywnie
bardzo świeża kwestia. Jako opensource zaistniał dopiero gdzieś w połowie
2005 r. No i wciąż nie można doczekać się wersji 1.0. Ale Django ma szansę
na to aby zdominować aplikacje webowe oparte na Pythonie. No chyba, że
Pylons poprawi dokumentację i promocję. Sądzę, że jest w stanie pobić
Django, ale nie z taką żałosną (tzn. prawie zerową) promocją!
>> wybitne (Agile web development...).
>
> dive into python
To jest raczej o samym języku, a nie o frameworku. Poza Zope/Plone i
ostatnie TurboGears to nic nie ma. Poza tym AWDwR została uznana w 2006 za
najlepszą ksiązkę techniczną na świecie na temat budowania aplikacji
webowych. Nie mówię że Dive jest zły, ale to trochę inna klasa i inny
temat.
Zresztą jak porównać to co wychodzi na temat Pythona z książkami jakie są
wydawane o Ruby (i nie tylko o Rails), to Python wygląda coraz bladziej
(nie mówię że się z tego cieszę bo życzę Pythonowi jak najlepiej) Rzuć tu
okiem: http://www.ruby-doc.org/bookstore
> poza rails nie ma w zasadzie popularnych aplikacji napisanych w rubym, w
> pythonie są, a web development to malutki wycinek zastosowań języków
> programowania
Nie taki znowu mały. Poza tym Ruby używa już NASA, Motorola, Lucent,
Siemens itp. A Sun wsparł JRuby zatrudniając jego developerów.
Jaroslaw Zabiello
To niech wydają następne. A TurboGears się nie zmienia razem z CherryPy? A
Rails się nie zmienia? Przecież RoR w wersji 1.1 wniósł ogromne zmiany.
Wychodząca aktualnie wersja 1.2 Railsów wnosi także duże zmiany.
Zresztą nawet jak nie książki, to chociaż niech poprawią dokumentację
online. Na razie to są wszystko jakieś porozrzucane fragmenty. W Django
mądrze zrobili, że od początku (otwarcia kodu) skupili się na dokumentacji
online. I słusznie. Bo jak ludzie nie mają dobrej dokumentacji to jak mają
w ogóle używać dany produkt? Nie mówię, że Pylons w ogóle nic nie ma. Ma,
ale to wszystko jest za mizerne. Np. próba wejścia w SQLAlchemy i Pylons to
przeżycie traumatyczne.
Jaroslaw Zabiello
> Było by skrajnie nieodpowiedzialnie pisać książkę o frmaeworku, który
> nie ma jeszcze wersji 1.0 i się co chwilę zmienia.
Twórcy Django mają odmienne zdanie. Właśnie piszą książkę do Django mimo że
nie ma wersji 1.0. Zobacz: http://www.djangobook.com/
climbus
> Dnia Tue, 12 Dec 2006 12:34:32 +0100, climbus napisał(a):
>
>> Było by skrajnie nieodpowiedzialnie pisać książkę o frmaeworku, który
>> nie ma jeszcze wersji 1.0 i się co chwilę zmienia.
>
> Twórcy Django mają odmienne zdanie. Właśnie piszą książkę do Django mimo że
> nie ma wersji 1.0. Zobacz: http://www.djangobook.com/
>
Akurat książka online to jest bardzo dobry pomysł.
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 12:28:05 +0100, Janusz A. Urbanowicz napisał(a):
>
>> dla sporej częsci control-freaków nie do przyjęcia jest znaczące
>> formatowanie kodu
>
> Zdedycydowanie przesadzasz.
naprawdę mam podać cytaty z ostatniej dyskusji o tabach?
na żywo też słyszałem takie teksty - ,,nie podejdę do pythona bo te spacje''
>>> wybitne (Agile web development...).
>>
>> dive into python
>
> To jest raczej o samym języku, a nie o frameworku. Poza Zope/Plone i
> ostatnie TurboGears to nic nie ma. Poza tym AWDwR została uznana w 2006 za
> najlepszą ksiązkę techniczną na świecie na temat budowania aplikacji
> webowych. Nie mówię że Dive jest zły, ale to trochę inna klasa i inny
> temat.
No ale kogo interesują aplikacje webowe na takim poziomie? Ani w
railsach ani w django nie napiszesz aplikacji obsługującej ~500 hitów
na sekundę. Przemysł aplikacji webowych pracuje w J2EE albo w .Net.
A pytanie było o ksiązkę o języku a nie o książkę o aplikacji.
> Zresztą jak porównać to co wychodzi na temat Pythona z książkami jakie są
> wydawane o Ruby (i nie tylko o Rails), to Python wygląda coraz bladziej
> (nie mówię że się z tego cieszę bo życzę Pythonowi jak najlepiej) Rzuć tu
> okiem: http://www.ruby-doc.org/bookstore
No fajnie ale mnie to mało obchodzi, są to fajne ksiązki do języka
który mnie nie interesuje na temat za który mi nikt nie płaci.
Przejrzałem. 90% tych książek jest o RoR który mnie nie interesuje, a
pozostałe 10 to ksiązki o programowaniu dla początkujących. *ziew*
>> poza rails nie ma w zasadzie popularnych aplikacji napisanych w rubym, w
>> pythonie są, a web development to malutki wycinek zastosowań języków
>> programowania
>
> Nie taki znowu mały. Poza tym Ruby używa już NASA, Motorola, Lucent,
> Siemens itp. A Sun wsparł JRuby zatrudniając jego developerów.
Your point being?
Uznam ruby za wartego zainetresowania kiedy przez zależności trafi do
base systemu debiana, to znaczy że jakiś kluczowy element systemu w
nim będzie napisany.
Jaroslaw Zabiello
> na żywo też słyszałem takie teksty - ,,nie podejdę do pythona bo te spacje''
Nie mówię, że tak czasem nie bywa. Ale to są jakieś uprzedzone jednostki i
takie głosy spotkasz w różnych środowiskach miłosników klamr w kodzie.
Zresztą to normalna reakcja, bo Python jest tu b. nietypowy. Ja też miałem
na początku mieszane uczucia. Aż zacząłem coś pisać w Pythonie. Wtedy to,
co wydawało się wadą nagle okazało się wielką zaletą. Wiele osób ma takie
doświadczenia. To po prostu siła przyzwyczajeń z innych języków.
> No ale kogo interesują aplikacje webowe na takim poziomie? Ani w
> railsach ani w django nie napiszesz aplikacji obsługującej ~500 hitów
> na sekundę.
Nie przesadzasz? Wszystko zależy od siły sprzętu. Czytałem o RoR dającym
3000 req/s. RoR się doskonale skaluje poziomo dzięki mongrelom.
> Przemysł aplikacji webowych pracuje w J2EE albo w .Net.
Na szczęście nie wszyscy. Te technologie są zdecydowanie za ciężkie do
większości typowych aplikacji internetowych. Stawiam nawet tezę że .NET to
pomyłka jeśli chodzi o budowanie aplikacji webowych.
> A pytanie było o ksiązkę o języku a nie o książkę o aplikacji.
Przecież jest PictAxe2, właśnie wydaje ją Helion. Ponad 1000 stron po
polsku. Mam ang. wersję. Jest niezła.
>> Zresztą jak porównać to co wychodzi na temat Pythona z książkami jakie są
>> wydawane o Ruby (i nie tylko o Rails), to Python wygląda coraz bladziej
>> (nie mówię że się z tego cieszę bo życzę Pythonowi jak najlepiej) Rzuć tu
>> okiem: http://www.ruby-doc.org/bookstore
>
> No fajnie ale mnie to mało obchodzi, są to fajne ksiązki do języka
> który mnie nie interesuje na temat za który mi nikt nie płaci.
To inna sprawa. Mnie akurat płaci, bo mam okazję pracować zarówno w
Pythonie jak i Ruby i Rails. Ja tylko zwróciłem uwagę, że sytuacja
wydawnicza i dostępna dokumentacja do Pythona jest słaba.
>> Poza tym Ruby używa już NASA, Motorola, Lucent, Siemens itp. A Sun
>> wsparł JRuby zatrudniając jego developerów.
>
> Your point being?
To, że Ruby to nie tylko Rails.
> Uznam ruby za wartego zainetresowania kiedy przez zależności trafi do
> base systemu debiana
Masz specyficzne oczekiwania, a mnie na dodatek mało obchodzi, aby cię do
czegoś przekonywać.
climbus
> No ale kogo interesują aplikacje webowe na takim poziomie? Ani w
> railsach ani w django nie napiszesz aplikacji obsługującej ~500 hitów
> na sekundę. Przemysł aplikacji webowych pracuje w J2EE albo w .Net.
Po pierwsze nie wiem czy nie da się napisać. Po drugie ile jest takich
serwisów w polsce? 4? http://www.futrega.org/etc/megapanel_czerwiec_2006.txt
Serwis oparty prawdopodobnie na django (grono.net) jest na 9 pozycji.
Z tą dominacją różnie bywa.
Climbus
Janusz A. Urbanowicz
>>> Zresztą jak porównać to co wychodzi na temat Pythona z książkami jakie są
>>> wydawane o Ruby (i nie tylko o Rails), to Python wygląda coraz bladziej
>>> (nie mówię że się z tego cieszę bo życzę Pythonowi jak najlepiej) Rzuć tu
>>> okiem: http://www.ruby-doc.org/bookstore
>>
>> No fajnie ale mnie to mało obchodzi, są to fajne ksiązki do języka
>> który mnie nie interesuje na temat za który mi nikt nie płaci.
>
> To inna sprawa. Mnie akurat płaci, bo mam okazję pracować zarówno w
> Pythonie jak i Ruby i Rails. Ja tylko zwróciłem uwagę, że sytuacja
> wydawnicza i dostępna dokumentacja do Pythona jest słaba.
Mi niczego do pythona nie brakuje.
>>> Poza tym Ruby używa już NASA, Motorola, Lucent, Siemens itp. A Sun
>>> wsparł JRuby zatrudniając jego developerów.
>>
>> Your point being?
>
> To, że Ruby to nie tylko Rails.
No więc tego to ZUPEŁNIE nie widać.
Rob Wolfe
> Heja
>
> O co chodzi z tym Ruby? sledze od czasu do czasu wiesci ze swiata tego
> jezyka, i odnosze wrazenie, ze jest go wiecej i wiecej, dynamika
> spolecznosci ruby tez jakby wieksza, mimo ze python jest starszy.
Opierasz to "wrażenie" na jakichś konkretnych podstawach,
czy może poprostu częściej odwiedzasz strony poświęcone Ruby
niż innym językom.
Porównałem sobie dla przykładu aktywność grup usenetowych
i Ruby w porównaniu z Pythonem wypada tu raczej blado:
comp.lang.python
http://netscan.research.microsoft.com/reportcard.aspx?tp=14&sd=12/5/2006&ng=comp.lang.python
comp.lang.ruby
http://netscan.research.microsoft.com/reportcard.aspx?tp=14&sd=12/5/2006&ng=comp.lang.ruby
pl.comp.lang.python
http://netscan.research.microsoft.com/reportcard.aspx?tp=14&sd=12/5/2006&ng=pl.comp.lang.python
pl.comp.lang.ruby
http://netscan.research.microsoft.com/reportcard.aspx?tp=14&sd=12/5/2006&ng=pl.comp.lang.ruby
> Skad takie zainteresowanie tym jezykiem? czy to Ruby on rails dzwignal go
> do takiej popularnosci? Na oko tak, ale w takim razie czemu python nie
> dorobil sie podobnego czegos?
Chyba trochę zaklinasz rzeczywistość. Jakoś nie widzę, aby Ruby zdominował
Pythona. Podaj jakieś obiektywne fakty, a nie posługuj się wrażeniami.
> Powiadaja, ze python mimo wszystko ma ladnieszja, prostsza, logiczniejsza
> itd skladnie.
Święta prawda.
> W takim razie czemu to w ruby powstal RoR? Moze po prostu
> dlatego, ze w nim sie pisze latwiej, szybciej mimo ze moze nie tak
> elegancko (czy jakkolwiek to nazwiemy)?
RoR to *jedyna* znana aplikacja w Ruby. W Pythonie jest ich wiele.
Porównaj sobie te dwie listy:
http://www.ruby-lang.org/en/documentation/success-stories/
http://www.python.org/about/success/
> Czy do pythona wyszla dobra ksiazka o nim? Dobra, tzn nie taka, ktora
> tylko opisuje jezyk, ale taka ktora pisze jak w nim efektywnie pisac
> programy? Ruby mam wrazenie, ze takowe ma, i to nie tylko dobre ale nawet
> okreslone jako wybitne (Agile web development...).
A widziałeś kiedyś takie książki jak:
"Dive into Python, "Python Cookbook", "Text Processing in Python",
"Problem Solving with Algorithms and Data Structures"?
To są *prawdziwe* książki dla programistów, a nie jakieś nudne
wprowadzenia.
> Czyzby ruby mial okazje zrobic to co python, tylko lepiej - tzn stac sie
> popularnym jezykiem o ktorym duzo i wszedzie sie gada no i uzywa?
Starasz się udowodnić z góry przyjętą tezę, ale nie przekonałeś
mnie ani na jotę, bo nie podałeś *żadnych* rzeczowych argumentów.
--
pozdrawiam
Rob
Janusz A. Urbanowicz
>> No ale kogo interesują aplikacje webowe na takim poziomie? Ani w
>> railsach ani w django nie napiszesz aplikacji obsługującej ~500 hitów
>> na sekundę. Przemysł aplikacji webowych pracuje w J2EE albo w .Net.
>
> Po pierwsze nie wiem czy nie da się napisać. Po drugie ile jest takich
> serwisów w polsce? 4?
> http://www.futrega.org/etc/megapanel_czerwiec_2006.txt
A kto mówi o domenie .pl?
W Polsce się je produkuje, nie używa, za mały rynek.
Jaroslaw Zabiello
> Mi niczego do pythona nie brakuje.
To sie ciesz. Ja chetnie bym wgryzl sie w Zope3, ale na tej dokumentacji co
jest to mozna tylko dostac stresu.
>> To, że Ruby to nie tylko Rails.
>
> No więc tego to ZUPEŁNIE nie widać.
Co chcesz? Ruby dopiero od niedawna staje sie szerzej znany. Jak wyjdzie
Ruby 2.0 z pelnym unicodem i maszyna wirtualna YARV to moze byc dodatkowa,
niezla zadyma. (Ruby 1.9 pod YARV jest jakies 10x szybszy)
Janusz A. Urbanowicz
> RoR to *jedyna* znana aplikacja w Ruby. W Pythonie jest ich wiele.
> Porównaj sobie te dwie listy:
> http://www.ruby-lang.org/en/documentation/success-stories/
> http://www.python.org/about/success/
A to jest zresztą bardzo ciekawe że railsy to railsy tamto a nie ma
żadnej znanej aplikacji OSS na railsach, jak chociażby railsowego
Wordpressa (PHP) czy Plone (Python/Zope). A ostatnio nawet szukałem
jakiegoś CMS dla klienta i patrzyłem na rzeczy railsowe.
climbus
> climbus <jkulesz...@murator.com.pl> writes:
>
>>> No ale kogo interesują aplikacje webowe na takim poziomie? Ani w
>>> railsach ani w django nie napiszesz aplikacji obsługującej ~500 hitów
>>> na sekundę. Przemysł aplikacji webowych pracuje w J2EE albo w .Net.
>> Po pierwsze nie wiem czy nie da się napisać. Po drugie ile jest takich
>> serwisów w polsce? 4?
>> http://www.futrega.org/etc/megapanel_czerwiec_2006.txt
>
> A kto mówi o domenie .pl?
>
> W Polsce się je produkuje, nie używa, za mały rynek.
Podałem przykład rynku. Nie sądzę aby % dużych do małych się mocno
zmieniał w różnych krajach.
Jaroslaw Zabiello
> Porównałem sobie dla przykładu aktywność grup usenetowych
> i Ruby w porównaniu z Pythonem wypada tu raczej blado:
Bo społeczność Pythona jest starsza i większa. To normalne. Ale wejdź sobie
tylko na irca od Railsów czy Rubiego i porównaj z Pythonem i Django...
> Jakoś nie widzę, aby Ruby zdominował Pythona. Podaj jakieś obiektywne fakty
Już teraz ilość książek powstających do Rubiego i Railsów przewyższa to co
powstaje do Pythona. To są fakty. Myślisz że tego nikt nie kupuje? :)
Railsy są rozpoznawane jakieś przynajmniej 100x bardziej niż Django czy
Pylons.
> To są *prawdziwe* książki dla programistów, a nie jakieś nudne
> wprowadzenia.
Dobry żart tynfa wart. :) Może ludzie potrzebują czegoś lekkiego i
błyskotliwie napisanego zamiast książek "dla prawdziwych programistów" lub
zbioru nudnych recept? (btw, mam "Python Cookbook", jest faktycznie nudna)
Agile Web Development in Rails (polecam 2ed) to naprawdę bardzo dobra
książka. Widać że nigdy jej nie czytałeś.
Janusz A. Urbanowicz
Dużej fajnej powszechnie używanej aplikacji infrastrukturalnej jak np
Mailman czy RT czy te co wymieniłem w innym poście. RoR to nie
aplikacja, to platforma.
W jednym moim projekcie był raz kawałek w rubym ale sie okazało że
trzeba to w C przepisać.
Jaroslaw Zabiello
> nie ma żadnej znanej aplikacji OSS na railsach, jak chociażby
> railsowego Wordpressa (PHP)
O przepraszam. Jest bardzo dobry Typo4. Używam go w blogu.
> czy Plone (Python/Zope).
Yes. Plone is the best :)
> A ostatnio nawet szukałem jakiegoś CMS dla klienta i
> patrzyłem na rzeczy railsowe.
W CMS to rządzi Plone albo PHP.
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 14:12:56 +0100, Rob Wolfe napisał(a):
>
>> Porównałem sobie dla przykładu aktywność grup usenetowych
>> i Ruby w porównaniu z Pythonem wypada tu raczej blado:
>
> Bo społeczność Pythona jest starsza i większa. To normalne. Ale wejdź sobie
> tylko na irca od Railsów czy Rubiego i porównaj z Pythonem i Django...
No ale ci tłumaczymy że na pisaniu stronek programowanie się nie kończy.
>> Jakoś nie widzę, aby Ruby zdominował Pythona. Podaj jakieś obiektywne fakty
>
> Już teraz ilość książek powstających do Rubiego i Railsów przewyższa to co
> powstaje do Pythona. To są fakty. Myślisz że tego nikt nie kupuje? :)
> Railsy są rozpoznawane jakieś przynajmniej 100x bardziej niż Django czy
> Pylons.
Patrz wyżej.
>> To są *prawdziwe* książki dla programistów, a nie jakieś nudne
>> wprowadzenia.
>
> Dobry żart tynfa wart. :) Może ludzie potrzebują czegoś lekkiego i
> błyskotliwie napisanego zamiast książek "dla prawdziwych programistów" lub
> zbioru nudnych recept? (btw, mam "Python Cookbook", jest faktycznie nudna)
> Agile Web Development in Rails (polecam 2ed) to naprawdę bardzo dobra
> książka. Widać że nigdy jej nie czytałeś.
Bo to wszystko to jest dla ludzi co chcą ,,robić stronki''. A później
taki nie jest w stanie wyjść poza myślenie kategoriami serwisów
webowych, a dalej to już sobie wyguglaj moje posty o programistach PHP
bo mi się nie chce powtarzać rantu.
I przy następnej rekrutacji do projektu będę kurwa odpytywał czym sie
różni SIGHUP od SIGSTOP (tak, miałem następną traumę). I 99% misiów co
się uczy z tych książek co to zachwalasz to nie będzie wiedziało o co
wogle kaman. I _dlatego_ te książki są z mojego punktu widzenia
bezwartościowe.
Jaroslaw Zabiello
> Dużej fajnej powszechnie używanej aplikacji infrastrukturalnej jak np
> Mailman czy RT czy te co wymieniłem w innym poście.
A dlaczego myślisz, że wszystko musi być pisane w jednym, słusznym języku?
Dzisiaj są czasy że pracuje się hybrydowo biorąc to co najlepsze z różnych
języków. Np. do forum używam PHP bo nie znam lepszego softu niż Invision
Power Board. Do CMS - Plone. Do szybkiej wyszukiwarki - Django. Do bloga
Typo4 który chodzi na RoR. Nie ma co się spierać który język jest lepszy.
Ważniejszym pytaniem jest to, do czego chcesz go użyć.
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 14:20:25 +0100, Janusz A. Urbanowicz napisał(a):
>
>> nie ma żadnej znanej aplikacji OSS na railsach, jak chociażby
>> railsowego Wordpressa (PHP)
>
> O przepraszam. Jest bardzo dobry Typo4. Używam go w blogu.
Ja nie pytam o dobry. Ja pytam o dobry i POPULARNY.
Janusz A. Urbanowicz
No więc sam właśnie powiedziałeś że Ruby nie ma killer app. I to jest
ten punkt że poza RoR to ruby wcale nie jest widoczny.
Jaroslaw Zabiello
>> Bo społeczność Pythona jest starsza i większa. To normalne. Ale wejdź sobie
>> tylko na irca od Railsów czy Rubiego i porównaj z Pythonem i Django...
>
> No ale ci tłumaczymy że na pisaniu stronek programowanie się nie kończy.
Stronek?? Ty chyba nie myślisz że pisanie aplikacji desktopowej jest
bardziej złożone niż wymłocenie dobrej aplikacji internetowej? :) Zresztą
co to mnie obchodzi. Wiekszość mojej pracy dotyczy internetu i jego
technologii. Być może pracujesz w innej branży. I dobrze.
>> Agile Web Development in Rails (polecam 2ed) to naprawdę bardzo dobra
>> książka. Widać że nigdy jej nie czytałeś.
>
> Bo to wszystko to jest dla ludzi co chcą ,,robić stronki''.
Gówno prawda. Do stronek to jest najlepszy PHP.
> I przy następnej rekrutacji do projektu będę kurwa odpytywał czym sie
> różni SIGHUP od SIGSTOP (tak, miałem następną traumę). I 99% misiów co
> się uczy z tych książek co to zachwalasz to nie będzie wiedziało o co
> wogle kaman. I _dlatego_ te książki są z mojego punktu widzenia
> bezwartościowe.
Zachowaj swój pkt. widzenia dla siebie. :) Wiadomo, że jedna książka
wszystkiego nie opisze. Agile, to książka o Railsach a nie o wszystkim co
dotyczy aplikacji webowych. To temat znacznie bardziej złozony.
Jaroslaw Zabiello
>> O przepraszam. Jest bardzo dobry Typo4. Używam go w blogu.
>
> Ja nie pytam o dobry. Ja pytam o dobry i POPULARNY.
O rany. To jest pojecie wzlędne. Mnie mało obchodzi co jest popularne.
Obchodzi mnie to co jest dobre. Popularny to jest PHP. I co z tego?
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 14:37:46 +0100, Janusz A. Urbanowicz napisał(a):
>
>>> O przepraszam. Jest bardzo dobry Typo4. Używam go w blogu.
>>
>> Ja nie pytam o dobry. Ja pytam o dobry i POPULARNY.
>
> O rany. To jest pojecie wzlędne. Mnie mało obchodzi co jest popularne.
> Obchodzi mnie to co jest dobre. Popularny to jest PHP. I co z tego?
No ale twoja teza była, że ruby jest coraz bardziej _popularny_. Tylko
że tego nie widać.
Jaroslaw Zabiello
> No więc sam właśnie powiedziałeś że Ruby nie ma killer app. I to jest
> ten punkt że poza RoR to ruby wcale nie jest widoczny.
Dzieki RoR wiele osób zaczyna interesować się Rubim. Nie odwrotnie. To
znaczy, że RoR jest killer appl Rubiego. RoR wywołał efekt lawiny.
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 14:40:21 +0100, Janusz A. Urbanowicz napisał(a):
>
>> No więc sam właśnie powiedziałeś że Ruby nie ma killer app. I to jest
>> ten punkt że poza RoR to ruby wcale nie jest widoczny.
>
> Dzieki RoR wiele osób zaczyna interesować się Rubim. Nie odwrotnie. To
> znaczy, że RoR jest killer appl Rubiego. RoR wywołał efekt lawiny.
To gdzie jest zalew wspaniałych aplikacji napisanych w Ruby/ROR?
Jak się interesują to chyba coś piszą, nie?
Czy tak po prostu szarpią bohatera oglądając słynne ruby videos
(MSPANC)?
Jaroslaw Zabiello
> No ale twoja teza była, że ruby jest coraz bardziej _popularny_. Tylko
> że tego nie widać.
Kto widzi, ten widzi. :) Może nie jest aż tak popularny abys ty to zauważył
w swojej branży. I tyle. Ale faktem jest że popularność Rubiego rośnie a
nie maleje.
Jaroslaw Zabiello
> To gdzie jest zalew wspaniałych aplikacji napisanych w Ruby/ROR?
Pobuszuj sobie na http://wiki.rubyonrails.org/rails. Problemem RoR (zresztą
dotyczy też Pythona) jest droższy i mniej popularny hosting niż takiego
PHP. Zalecanym hostingiem dla RoR jest VPS (lub dedykowany serwer). Można
na takim dreamhoście, który jest shared hosting.
Janusz A. Urbanowicz
Stary, w tej skali rynek to jest EMEA a nie jakieś państewka.
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 14:49:06 +0100, Janusz A. Urbanowicz napisał(a):
>
>> To gdzie jest zalew wspaniałych aplikacji napisanych w Ruby/ROR?
>
> Pobuszuj sobie na http://wiki.rubyonrails.org/rails. Problemem RoR (zresztą
> dotyczy też Pythona) jest droższy i mniej popularny hosting niż takiego
> PHP. Zalecanym hostingiem dla RoR jest VPS (lub dedykowany serwer). Można
> na takim dreamhoście, który jest shared hosting.
Posukałem sobie paczkowanych w debianie. W rubym jest napisane pare
trywiałów typu wiki i bot ircowy. A w/w wiki leży.
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 14:35:34 +0100, Janusz A. Urbanowicz napisał(a):
>
>>> Bo społeczność Pythona jest starsza i większa. To normalne. Ale wejdź sobie
>>> tylko na irca od Railsów czy Rubiego i porównaj z Pythonem i Django...
>>
>> No ale ci tłumaczymy że na pisaniu stronek programowanie się nie kończy.
>
> Stronek?? Ty chyba nie myślisz że pisanie aplikacji desktopowej jest
> bardziej złożone niż wymłocenie dobrej aplikacji internetowej? :) Zresztą
> co to mnie obchodzi. Wiekszość mojej pracy dotyczy internetu i jego
> technologii. Być może pracujesz w innej branży. I dobrze.
Niestety w dość zbliżonej.
> Zachowaj swój pkt. widzenia dla siebie. :) Wiadomo, że jedna książka
> wszystkiego nie opisze. Agile, to książka o Railsach a nie o wszystkim co
> dotyczy aplikacji webowych. To temat znacznie bardziej złozony.
Naprawdę?
Robert
Jaroslaw Zabiello napisał(a):
> Nie przesadzasz? Wszystko zależy od siły sprzętu. Czytałem o RoR dającym
> 3000 req/s. RoR się doskonale skaluje poziomo dzięki mongrelom.
Na czym to odpalili, na Crayu? Nawet mocne współczesne systemy
(1-procesorowe) z najszybszymi serwerami http (nginx) mają problem w
przekroczeniu 15k req/s *statycznych* plików.
> Na szczęście nie wszyscy. Te technologie są zdecydowanie za ciężkie do
> większości typowych aplikacji internetowych. Stawiam nawet tezę że .NET to
> pomyłka jeśli chodzi o budowanie aplikacji webowych.
Oczywiście za Twoimi tezami stoi ogromne doświadczenie, tak?
Robert
Jaroslaw Zabiello napisał(a):
> Stronek?? Ty chyba nie myślisz że pisanie aplikacji desktopowej jest
> bardziej złożone niż wymłocenie dobrej aplikacji internetowej? :)
A nie jest? Np. nie sądzę, żeby istniała aplikacja webowa mająca
nawet na bardzo dalekim horyzoncie złożoność algorytmiczną x264
albo inżynieryjną jajka linuxa.
Janusz A. Urbanowicz
Dla kol Zabiełły aplikacja desktopowa najwyraźniej składa się z paru
formatek w Glade i zapytań do SQLa...
Szkoda że goście z Tandberga (jak już jesteśmy w tych klimatach) nie
wiedzą jakie to proste, ostatnio zaśpiewali naście tysięcy euro za
aplikację desktopową...
Jaroslaw Zabiello
>> Czytałem o RoR dającym 3000 req/s. RoR się doskonale skaluje poziomo
>> dzięki mongrelom.
>
> Na czym to odpalili, na Crayu?
Nie. Jakis klaster.
>> Stawiam nawet tezę że .NET to pomyłka jeśli chodzi o budowanie aplikacji
>> webowych.
>
> Oczywiście za Twoimi tezami stoi ogromne doświadczenie, tak?
Wystarczy mi to co widziałem. Ciągła rekompilacja DLL przy zmianie
jakiejkolwiek pierdoły w kodzie. IIS nie pozwalający na szykie usunięcie z
pamięci starych DLL. Całe dni stracone na szukaniu błędu. Istny koszmar.
Kluczowa dla webu szybka petla sprzężenia zwrotnego i praca interaktywna
zupełnie tam nie ma racji bytu.
Robert
Robert napisał(a):
> A nie jest? Np. nie sądzę, żeby istniała aplikacja webowa mająca
> nawet na bardzo dalekim horyzoncie złożoność algorytmiczną x264
> albo inżynieryjną jajka linuxa.
A jak się ktoś będzie czepiał, że x264 i kernel to nie są
aplikacje desktopowe we właściwym sensie tego słowa, to proszę
rozważ np. coś takiego jak Photoshop. Nota bene, w którymś z
ostatnich wywiadów Stroustrup powiedział, że kod Photoshopa (C++)
jest jednym z najelegantszych, jakie w życiu widział.
Jaroslaw Zabiello
>> Pobuszuj sobie na http://wiki.rubyonrails.org/rails. Problemem RoR (zresztą
>> dotyczy też Pythona) jest droższy i mniej popularny hosting niż takiego
>> PHP. Zalecanym hostingiem dla RoR jest VPS (lub dedykowany serwer). Można
>> na takim dreamhoście, który jest shared hosting.
>
> Posukałem sobie paczkowanych w debianie. W rubym jest napisane pare
> trywiałów typu wiki i bot ircowy. A w/w wiki leży.
Akurat to wiki jest gównianie, bo za łatwo zapchać je spamem. Ale już
cofnąłem wersję. Tu masz troche aplikacji:
http://wiki.rubyonrails.com/rails/pages/RealWorldUsagePage1
http://wiki.rubyonrails.com/rails/pages/RealWorldUsagePage2
Jest tez Ferret, podobno dobry port Lucene w Ruby.
http://www.oreillynet.com/onlamp/blog/2005/10/lucene_in_ruby_name_ferret_thi.html
Tu jest o tym, że popularnosc Rubiego rosnie szybciej od Pythona
http://wiki.rubyonrails.com/rails/pages/RealWorldUsagePage1
Ilosc nowych projektow w Railsach takze znacznie bardziej rosnie niz w
Pythonie, PHP czy Perlu: http://ohloh.net/wiki/articles/php_eats_rails
Janusz A. Urbanowicz
> Robert napisał(a):
>
>> A nie jest? Np. nie sądzę, żeby istniała aplikacja webowa mająca
>> nawet na bardzo dalekim horyzoncie złożoność algorytmiczną x264
>> albo inżynieryjną jajka linuxa.
>
> A jak się ktoś będzie czepiał, że x264 i kernel to nie są
H.264 w którym profilu :-D?
Jaroslaw Zabiello
>> Wiadomo, że jedna książka wszystkiego nie opisze. Agile, to książka o
>> Railsach a nie o wszystkim co dotyczy aplikacji webowych. To temat
>> znacznie bardziej złozony.
>
> Naprawdę?
A masz jakies watpliwosci?
Rob Wolfe
> Dnia Tue, 12 Dec 2006 14:12:56 +0100, Rob Wolfe napisał(a):
> Już teraz ilość książek powstających do Rubiego i Railsów przewyższa to co
> powstaje do Pythona. To są fakty. Myślisz że tego nikt nie kupuje? :)
Rzecz nie w ilości, a w jakości. Policz ile jest książek do javy,
a ile jest wartych zakupu. Trzaskanie kolejnych wprowadzeń do języka
do żaden problem, tylko po co?
> Railsy są rozpoznawane jakieś przynajmniej 100x bardziej niż Django czy
> Pylons.
Mailman jest rozpoznawany... jakby to rzec... nieskończenie bardziej
niż nieistniejący odpowiednik w Ruby. :)
>> To są *prawdziwe* książki dla programistów, a nie jakieś nudne
>> wprowadzenia.
>
> Dobry żart tynfa wart. :) Może ludzie potrzebują czegoś lekkiego i
> błyskotliwie napisanego zamiast książek "dla prawdziwych programistów" lub
Średnio mnie obchodzi co potrzebują ludzie. Obchodzi mnie natomiast,
czego potrzebują programiści. "Błyskotliwe" opowiastki o Rails
mają się nijak do nauki programowania jako takiego.
> zbioru nudnych recept? (btw, mam "Python Cookbook", jest faktycznie nudna)
Albo jej nie czytałeś i zgadujesz po tytule albo przejrzałeś wyrywkowo.
Każdy rozdział dotyczy konkretnej problematyki i jest mnóstwo ciekawych
analiz algorytmów. To jest przecież sól programowania, czyż nie?
> Agile Web Development in Rails (polecam 2ed) to naprawdę bardzo dobra
> książka. Widać że nigdy jej nie czytałeś.
Zgadza się nie czytałem, bo akurat tematyka web'owa nie jest mi bliska.
Wynika z tego, że poznawanie Ruby'iego ma sens tylko wtedy, gdy ktoś
ma zamiar tworzyć coś na bazie Rails, tak?
--
pozdrawiam
Rob
Jaroslaw Zabiello
Nie kazda aplikacja to od razu jadro linuksa. Wszystko zalezy co porownac.
Robert
Jaroslaw Zabiello napisał(a):
> >> Stawiam nawet tezę że .NET to pomyłka jeśli chodzi o budowanie aplikacji
> >> webowych.
> >
> > Oczywiście za Twoimi tezami stoi ogromne doświadczenie, tak?
>
> Wystarczy mi to co widziałem. Ciągła rekompilacja DLL przy zmianie
> jakiejkolwiek pierdoły w kodzie. IIS nie pozwalający na szykie usunięcie z
> pamięci starych DLL. Całe dni stracone na szukaniu błędu. Istny koszmar.
> Kluczowa dla webu szybka petla sprzężenia zwrotnego i praca interaktywna
> zupełnie tam nie ma racji bytu.
Co to jest "kluczowa dla webu szybka petla sprzężenia zwrotnego i
praca interaktywna"?
Rozumiem, że piszesz o .necie, bo w przypadku javy nie wchodzą w grę
te problemy. Ale o co Ci chodzi z rekompilacją DLL??? Jak np. w
Pythonie pisząc zmieniasz wersję jakiejś paczki, to też masz masę
bólu z podbiciem wersji zależnych pakietów i przetestowaniem tego...
Robert
Janusz A. Urbanowicz napisał(a):
> "Robert" <rsze...@mat.uni.torun.pl> writes:
>
> > Robert napisał(a):
> >
> >> A nie jest? Np. nie sądzę, żeby istniała aplikacja webowa mająca
> >> nawet na bardzo dalekim horyzoncie złożoność algorytmiczną x264
> >> albo inżynieryjną jajka linuxa.
> >
> > A jak się ktoś będzie czepiał, że x264 i kernel to nie są
>
> H.264 w którym profilu :-D?
Nie kumam żartu :( Chodziło mi o x264 -
http://developers.videolan.org/x264.html
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 15:04:14 +0100, Janusz A. Urbanowicz napisał(a):
>
>>> Wiadomo, że jedna książka wszystkiego nie opisze. Agile, to książka o
>>> Railsach a nie o wszystkim co dotyczy aplikacji webowych. To temat
>>> znacznie bardziej złozony.
>>
>> Naprawdę?
>
> A masz jakies watpliwosci?
Jedną. Jak mocno kopać kolesi co znają tylko programowanie webowe a
odpowiadają na ogłoszenia o pracy dla _programistów_.
Robert
Rob Wolfe napisał(a):
> Średnio mnie obchodzi co potrzebują ludzie. Obchodzi mnie natomiast,
> czego potrzebują programiści. "Błyskotliwe" opowiastki o Rails
> mają się nijak do nauki programowania jako takiego.
O, i tutaj pasuje doskonale cytat ze Stroustrupa (z tego wywiadu, co
wyżej wspomniałem - http://www.technologyreview.com/InfoTech/17868/):
"The idea of programming as a semiskilled task, practiced by people
with a few months' training, is dangerous. We wouldn't tolerate
plumbers or accountants that poorly educated. We don't have as an aim
that architecture (of buildings) and engineering (of bridges and
trains) should become more accessible to people with progressively less
training. Indeed, one serious problem is that currently, too many
software developers are undereducated and undertrained."
Janusz A. Urbanowicz
I prawidłowo. http://en.wikipedia.org/wiki/H.264#Profiles
Robert
Jaroslaw Zabiello napisał(a):
Jak sądzę twierdziłeś, że napisanie dobrej aplikacji internetowej
jest bardziej złożone, niż aplikacji desktopowej... no więc masz
masę kontrprzykładów, to się teraz nie wymiguj.
Rob Wolfe
> Jaroslaw Zabiello <hipert...@gmail.com> writes:
>
>> Dnia Tue, 12 Dec 2006 14:12:56 +0100, Rob Wolfe napisał(a):
>>
>>> Porównałem sobie dla przykładu aktywność grup usenetowych
>>> i Ruby w porównaniu z Pythonem wypada tu raczej blado:
>>
>> Bo społeczność Pythona jest starsza i większa. To normalne. Ale wejdź sobie
>> tylko na irca od Railsów czy Rubiego i porównaj z Pythonem i Django...
>
> No ale ci tłumaczymy że na pisaniu stronek programowanie się nie kończy.
Święta prawda.
I nie powinno się zaczynać, bo potem mamy kolesi, którzy po przejściu
z HTML-a na PHP-a myślą, że wiedzą już wszystko.
>> Dobry żart tynfa wart. :) Może ludzie potrzebują czegoś lekkiego i
>> błyskotliwie napisanego zamiast książek "dla prawdziwych programistów" lub
>> zbioru nudnych recept? (btw, mam "Python Cookbook", jest faktycznie nudna)
>> Agile Web Development in Rails (polecam 2ed) to naprawdę bardzo dobra
>> książka. Widać że nigdy jej nie czytałeś.
>
> Bo to wszystko to jest dla ludzi co chcą ,,robić stronki''. A później
> taki nie jest w stanie wyjść poza myślenie kategoriami serwisów
> webowych, a dalej to już sobie wyguglaj moje posty o programistach PHP
> bo mi się nie chce powtarzać rantu.
Oj, pamiętam. :)
> I przy następnej rekrutacji do projektu będę kurwa odpytywał czym sie
> różni SIGHUP od SIGSTOP (tak, miałem następną traumę). I 99% misiów co
Wiem, że Ci nie do śmiechu, ale ja mogę tylko
ROTFL
> się uczy z tych książek co to zachwalasz to nie będzie wiedziało o co
> wogle kaman. I _dlatego_ te książki są z mojego punktu widzenia
> bezwartościowe.
Są dobre jako uzupełnienie solidnych podstaw, a nie jako źródło
nauki programowania.
--
pozdrawiam
Rob
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 15:02:50 +0100, Janusz A. Urbanowicz napisał(a):
>
>>> Pobuszuj sobie na http://wiki.rubyonrails.org/rails. Problemem RoR (zresztą
>>> dotyczy też Pythona) jest droższy i mniej popularny hosting niż takiego
>>> PHP. Zalecanym hostingiem dla RoR jest VPS (lub dedykowany serwer). Można
>>> na takim dreamhoście, który jest shared hosting.
>>
>> Posukałem sobie paczkowanych w debianie. W rubym jest napisane pare
>> trywiałów typu wiki i bot ircowy. A w/w wiki leży.
[]
> Jest tez Ferret, podobno dobry port Lucene w Ruby.
> http://www.oreillynet.com/onlamp/blog/2005/10/lucene_in_ruby_name_ferret_thi.html
Której litery w słowie ,,aplikacja'' nie umiesz przeczytać?
Janusz A. Urbanowicz
> Jaroslaw Zabiello napisał(a):
>
>> Nie przesadzasz? Wszystko zależy od siły sprzętu. Czytałem o RoR dającym
>> 3000 req/s. RoR się doskonale skaluje poziomo dzięki mongrelom.
>
> Na czym to odpalili, na Crayu? Nawet mocne współczesne systemy
for the record, cray sie slabo nadaje na serwer www
Piotr L.
Eh, trudno kernela nazwac aplikacja desktopowa. Kernel, to no kernel i
tyle.
Pomiedzy kernelem i 'stronkami' www jest cala masa roznego talatajstwa.
hm, tylko o czym to my gadali?
P.
climbus
> Jedną. Jak mocno kopać kolesi co znają tylko programowanie webowe a
> odpowiadają na ogłoszenia o pracy dla _programistów_.
Tutaj to przesadzasz. Wśród ogłoszeń dla programistów jest wiele dla
programistów webowych. I nie sądzę aby programiści webowi byli gorsi czy
nie byli programistami. Oczywiście jest znaczna ilość motłochu ale nie
znaczy to, że wśród nich nie ma ludzi wartościowych.
Spotkałem programistów, którzy byli świetnie wyszkoleni technicznie,
sypali pojęciami, kodowali najtrudniejsze algorytmy w c ale za nic nie
nadawali się do pracy. Nie potrafili wykonywać zadań na czas itp.
Jeżeli chcesz kopać kolesi, którzy szukają pracy to może jednak nie
powinieneś brać udziału w rekrutacji. Zajmij się swoim zadaniem, czyli
programowaniem.
Climbus
Adam Karpierz
> Jak sądzę twierdziłeś, że napisanie dobrej aplikacji internetowej
> jest bardziej złożone, niż aplikacji desktopowej... no więc masz
> masę kontrprzykładów, to się teraz nie wymiguj.
Mase kontprzykladow ?
Nie widze _ani jednego_ sensownego ?
Napisanie aplikacji Webowej jest o bardziej
skomplikowane niz napisanie rownowaznej jej
aplikacji desktopowej.
Owszem.. To jest generalnie minus (niedojrzalosc) technologii
webowych ale... tak wlasnie jest - czy sie to komus podoba czy nie.
Ajax tu tez zbawienia zadnego nie przyniosl.
AK
Robert
Piotr L. napisał(a):
No to napisałem: Photoshop - typowo desktopowa aplikacja.
Ideologicznym prawie odpowiednikiem RoR byłby x264 (biblioteka),
różnica w skali złożoności chyba nie wymaga komentowania. A to
jest oczywiście czubek góry lodowej.
Jaroslaw Zabiello
> Co to jest "kluczowa dla webu szybka petla sprzężenia zwrotnego i
> praca interaktywna"?
Chodzi o szybkosc zobaczenia wyniku aplikacji po jakiejs zmianie w kodzie.
Robert
Adam Karpierz napisał(a):
> "Robert" <rsze...@mat.uni.torun.pl> wrote in message
>
> > Jak sądzę twierdziłeś, że napisanie dobrej aplikacji internetowej
> > jest bardziej złożone, niż aplikacji desktopowej... no więc masz
> > masę kontrprzykładów, to się teraz nie wymiguj.
>
> Mase kontprzykladow ?
> Nie widze _ani jednego_ sensownego ?
Photoshop? Nie chce mi się więcej wymyślać, ale są TYSIĄCE. O, na
przykład taki Doom 39 czy jaka tam jest ostatnia wersja :)
> Napisanie aplikacji Webowej jest o bardziej
> skomplikowane niz napisanie rownowaznej jej
> aplikacji desktopowej.
*równoważnej*, tego założenia nie było w stwierdzeniu OP. Przy
takim postawieniu sprawy trudno się nie zgodzić, to tak samo jakby
porównać kodowanie równoważnego kodu w C i asemblerze (no, może
trochę przesadzam).
Adam Karpierz
> *równoważnej*, tego założenia nie było w stwierdzeniu OP.
No to k... mamy porownywac "desktopowy" program
symulatora lotniczego z BLOGiem Pana Zabielly ?! :(
zeby _jednak_ wykazac wieksza trudnosc "desktopow" ?
PANMSP...
AK
Adam Karpierz
Robert
Adam Karpierz napisał(a):
No z pretensjami do pana Z. - on zaczął te porównania.
Janusz A. Urbanowicz
>> Jedną. Jak mocno kopać kolesi co znają tylko programowanie webowe a
>> odpowiadają na ogłoszenia o pracy dla _programistów_.
>
> Tutaj to przesadzasz. Wśród ogłoszeń dla programistów jest wiele dla
> programistów webowych. I nie sądzę aby programiści webowi byli gorsi
> czy nie byli programistami. Oczywiście jest znaczna ilość motłochu ale
> nie znaczy to, że wśród nich nie ma ludzi wartościowych.
>
> Spotkałem programistów, którzy byli świetnie wyszkoleni technicznie,
> sypali pojęciami, kodowali najtrudniejsze algorytmy w c ale za nic nie
> nadawali się do pracy. Nie potrafili wykonywać zadań na czas itp.
A to już jest problem kierownika projektu.
> Jeżeli chcesz kopać kolesi, którzy szukają pracy to może jednak nie
> powinieneś brać udziału w rekrutacji. Zajmij się swoim zadaniem, czyli
> programowaniem.
To może niech nie odpisują na ogłoszenia gdzie jest napisane ,,solid
Unix background required'' _pomimo_ że jest to praca dla programisty
webowego.
A co do moich zadań to dziękuję za zainteresowanie, ale ja nie jestem
programistą jako takim.
Janusz A. Urbanowicz
> "Robert" <rsze...@mat.uni.torun.pl> wrote in message
>
>> Jak sądzę twierdziłeś, że napisanie dobrej aplikacji internetowej
>> jest bardziej złożone, niż aplikacji desktopowej... no więc masz
>> masę kontrprzykładów, to się teraz nie wymiguj.
>
> Mase kontprzykladow ?
> Nie widze _ani jednego_ sensownego ?
>
> Napisanie aplikacji Webowej jest o bardziej
> skomplikowane niz napisanie rownowaznej jej
> aplikacji desktopowej.
napisanie X11 (albo nawet - jednego drivera do) jest dla ciebie
prostsze niż napisanie aplikacji webowej?
szacun
Adam Karpierz
> napisanie X11 (albo nawet - jednego drivera do) jest dla ciebie
> prostsze niż napisanie aplikacji webowej?
Nie kompromituj sie.
kod X11 ma dokladnie tak do aplikacji desktopowej
co kod socketow, IP, HTTP, kod serwera http i przegladarki
internetowej do aplikacji Webowej.
AK
Jaroslaw Zabiello
> Trzaskanie kolejnych wprowadzeń do języka do żaden problem, tylko po co?
Jak to po co? Jak jest popyt to trzeba dostarczyć podaż. :) poza tym to nie
są same wprowadzenia. Mam np. The Ruby Way 2nd ed. To książka pisana z
założeniem, że już trochę Rubiego znasz.
> Mailman jest rozpoznawany... jakby to rzec... nieskończenie bardziej
> niż nieistniejący odpowiednik w Ruby. :)
Chcesz powiedzieć, że Mailman jest nieskończenie bardziej rozpoznawany
także od krasnoludków, których też nie ma? :)
> Obchodzi mnie natomiast, czego potrzebują programiści.
Programiści...czego? Sterowników pod windozę? Może mów za siebie.
> "Błyskotliwe" opowiastki o Rails mają się nijak do nauki
> programowania jako takiego.
...jak i nijak do przepisu na upieczenie ciasta. Rails to framework silnie
oparty na wzorcu MVC. W pewnym sensie uczy dobrego programania. Weź takiego
typowego pehapowca. Tłucze ten swój spaggethi code i jeśli w końcu nie
potłucze się, to pewnie nie wpadnie na pomysł aby zrobić to bardziej "z
głową". Rails od początku wymusza dobry podział kodu. I to jest dobre.
Oczywiście dla doświadczonych programsitów to nic odkrywczego. Odkrywcze
jest może DRY i ten minimalizm kodu jaki wymagają Railsy.
> Każdy rozdział dotyczy konkretnej problematyki i jest mnóstwo ciekawych
> analiz algorytmów. To jest przecież sól programowania, czyż nie?
Może nudna to za mocne słowo. Ale nie nadaje się do czytania od deski do
deski. Raczej jako taka encyklopedia rozwiązań. Sięgasz jak coś
potrzebujesz.
> Wynika z tego, że poznawanie Ruby'iego ma sens tylko wtedy, gdy ktoś
> ma zamiar tworzyć coś na bazie Rails, tak?
Oczywiście że nie. Kilka skryptów mam już w Ruby zamiast w Pythonie bo
wyglądają estetyczniej. :) Najczęściej jednak wiekszość styka się z Ruby po
usłyszeniu o wpierw Railsach.
Janusz A. Urbanowicz
>> "Błyskotliwe" opowiastki o Rails mają się nijak do nauki
>> programowania jako takiego.
>
> ...jak i nijak do przepisu na upieczenie ciasta. Rails to framework silnie
> oparty na wzorcu MVC. W pewnym sensie uczy dobrego programania. Weź takiego
> typowego pehapowca. Tłucze ten swój spaggethi code i jeśli w końcu nie
> potłucze się, to pewnie nie wpadnie na pomysł aby zrobić to bardziej "z
> głową". Rails od początku wymusza dobry podział kodu. I to jest dobre.
> Oczywiście dla doświadczonych programsitów to nic odkrywczego. Odkrywcze
> jest może DRY i ten minimalizm kodu jaki wymagają Railsy.
A teraz wyobraź sobie serwer sieciowego dooma napisany przez kogoś kto
programować się uczył na Railsach.
Janusz A. Urbanowicz
A bo to wszystko wynika z założeń biznesowych, ale to temat na inną dyskusję.
Jaroslaw Zabiello
> A teraz wyobraź sobie serwer sieciowego dooma napisany przez kogoś kto
> programować się uczył na Railsach.
Głupie porównanie. A czy ktoś może się uczyć programować na bazie
frameworka? Rails to tylko framework i to nie do wszystkich zastosowań.
Jest bardzo dobry jako lekki fronton korzystający z relacyjnej bazy danych.
Prosty, przyjemny, szybki do nauki i zbudowania aplikacji dającej także
czytelny kod. Ale to nie żaden serwer aplikacyjny ani jakieś uniwersalne
panaceum na wszystkie możliwe problemy programowania sieciowego. Czy wy za
dużo aby od tego RoR nie oczekujecie? :)
Janusz A. Urbanowicz
> Dnia Tue, 12 Dec 2006 16:17:41 +0100, Janusz A. Urbanowicz napisał(a):
>
>> A teraz wyobraź sobie serwer sieciowego dooma napisany przez kogoś kto
>> programować się uczył na Railsach.
>
> Głupie porównanie.
Bardzo dobre porównanie. Serwer dooma też jest aplikacją internetową,
też ma swoje dane, ale model MVC nie ma tu zastosowania. I co teraz?
> A czy ktoś może się uczyć programować na bazie frameworka? Rails to
> tylko framework i to nie do wszystkich zastosowań. Jest bardzo
> dobry jako lekki fronton korzystający z relacyjnej bazy danych.
> Prosty, przyjemny, szybki do nauki i zbudowania aplikacji dającej
> także czytelny kod. Ale to nie żaden serwer aplikacyjny ani jakieś
> uniwersalne panaceum na wszystkie możliwe problemy programowania
> sieciowego. Czy wy za dużo aby od tego RoR nie oczekujecie? :)
To ty nam sprzedajesz RoR jako panaceum i to ty sugerowałeś że małpa
prosto z drzewa posadzona do RoR nauczy się dobrze programować w
sensie ogólnym.
Aint that cute? But its WROOOONG!
Jaroslaw Zabiello
> Bardzo dobre porównanie. Serwer dooma też jest aplikacją internetową,
> też ma swoje dane, ale model MVC nie ma tu zastosowania. I co teraz?
To, że do tego RoR sie nie nadaje.
>> A czy ktoś może się uczyć programować na bazie frameworka? Rails to
>> tylko framework i to nie do wszystkich zastosowań. Jest bardzo
>> dobry jako lekki fronton korzystający z relacyjnej bazy danych.
>> Prosty, przyjemny, szybki do nauki i zbudowania aplikacji dającej
>> także czytelny kod. Ale to nie żaden serwer aplikacyjny ani jakieś
>> uniwersalne panaceum na wszystkie możliwe problemy programowania
>> sieciowego. Czy wy za dużo aby od tego RoR nie oczekujecie? :)
>
> To ty nam sprzedajesz RoR jako panaceum
Nieprawda. Gdzie tak napisałem?
> i to ty sugerowałeś że małpa prosto z drzewa posadzona do RoR nauczy
> się dobrze programować w sensie ogólnym.
Bzdura. Gdzie tak napisałem?
Coś ci się uroiło.
Adam Karpierz
> To może niech nie odpisują na ogłoszenia gdzie jest napisane ,,solid
> Unix background required'' _pomimo_ że jest to praca dla programisty
> webowego.
Wymaganie od programisty
,,solid Unix background required''
jest z gruntu chore.
PS: Co rozumiesz pod pojeciem ,,solid Unix background required''
bo moze myslimy o czyms zupelnie innym ?
AK
Adam Karpierz
> Bardzo dobre porównanie. Serwer dooma też jest aplikacją internetową,
> też ma swoje dane, ale model MVC nie ma tu zastosowania. I co teraz?
A to dlaczego nie ma ?
To Ci ciekawostka ?
Mozesz mi wytlumaczyc _co_ powoduje ze nie mozna uzyc MVC
w serwerze dooma ?
AK
Janusz A. Urbanowicz
A gdzie tam masz prezentację (view)?
Janusz A. Urbanowicz
> "Janusz A. Urbanowicz" <al...@bofh.org.pl> wrote:
>
>> To może niech nie odpisują na ogłoszenia gdzie jest napisane ,,solid
>> Unix background required'' _pomimo_ że jest to praca dla programisty
>> webowego.
>
> Wymaganie od programisty
> ,,solid Unix background required''
> jest z gruntu chore.
dlaczego? poważnie pytam
Janusz A. Urbanowicz
>> I przy następnej rekrutacji do projektu będę kurwa odpytywał czym sie
>> różni SIGHUP od SIGSTOP (tak, miałem następną traumę). I 99% misiów co
>
> Wiem, że Ci nie do śmiechu, ale ja mogę tylko
> ROTFL
Ale już ostatnią bo mam nowego człowieka.
Adam Karpierz
> dlaczego? poważnie pytam
Najpierw Ty odpowiedz na pytanie:
PS: Co rozumiesz pod pojeciem ,,solid Unix background required''
bo moze myslimy o czyms zupelnie innym ?
To stworzy podstawy do dyskusji.
AK
Adam Karpierz
>> A to dlaczego nie ma ?
>> To Ci ciekawostka ?
>> Mozesz mi wytlumaczyc _co_ powoduje ze nie mozna uzyc MVC
>> w serwerze dooma ?
>
> A gdzie tam masz prezentację (view)?
Ze niby co ?
Doom nie ma wartswy prezentacji ?
AK
Janusz A. Urbanowicz
> "Janusz A. Urbanowicz" <al...@bofh.org.pl> wrote:
>
>> dlaczego? poważnie pytam
>
> Najpierw Ty odpowiedz na pytanie:
> PS: Co rozumiesz pod pojeciem ,,solid Unix background required''
> bo moze myslimy o czyms zupelnie innym ?
Żeny wiedział o istnieniu świata poza /var/www i apachem, jak działa
proces i co z tego wynika, jakie są usługi systemowe i po co i trochę
o własnośćiach unixa jako takiego (np wspomniane sygnały)
grzesiek
Janusz A. Urbanowicz napisał(a):
> Jaroslaw Zabiello <hipert...@gmail.com> writes:
>
> > Dnia Tue, 12 Dec 2006 15:04:14 +0100, Janusz A. Urbanowicz napisał(a):
> >
> >>> Wiadomo, że jedna książka wszystkiego nie opisze. Agile, to książka o
> >>> Railsach a nie o wszystkim co dotyczy aplikacji webowych. To temat
> >>> znacznie bardziej złozony.
> >>
> >> Naprawdę?
> >
> > A masz jakies watpliwosci?
>
> Jedną. Jak mocno kopać kolesi co znają tylko programowanie webowe a
> odpowiadają na ogłoszenia o pracy dla _programistów_.
Ja bym proponował wpierw zapytać sie, profilaktycznie, czy koleś nie
ma przypadkiem 4 dana :)
forgems
> railsach ani w django nie napiszesz aplikacji obsługującej ~500 hitów
> na sekundę. Przemysł aplikacji webowych pracuje w J2EE albo w .Net.
YouTube z nowości ?:)
Aplikacji webowych nie skaluje się wertykalnie tylko horyzontalnie.
Pozdrawiam
Marcin Swiderski
Marcin Jurczuk
> Szkoda że goście z Tandberga (jak już jesteśmy w tych klimatach) nie
> wiedzą jakie to proste, ostatnio zaśpiewali naście tysięcy euro za
> aplikację desktopową...
Tego Tandberga od Digital TV ?
Oni są wogóle dziwni bo za każdą rzecz solidnie śpiewają.
Podobnie inna firma z branży - Trilithic.
Ale to OT :)
Robert
forgems napisał(a):
> > > temat.No ale kogo interesują aplikacje webowe na takim poziomie? Ani w
> > railsach ani w django nie napiszesz aplikacji obsługującej ~500 hitów
> > na sekundę. Przemysł aplikacji webowych pracuje w J2EE albo w .Net.
> YouTube z nowości ?:)
A w czym jest zrobiony YouTube?
> Aplikacji webowych nie skaluje się wertykalnie tylko horyzontalnie.
Chyba, że chodzi o czas odpowiedzi. Sto 286-ek to nie to samo, co
porządny paroprockowy Xeon. To jest szczególnie ważne w przypadku
serwerów baz danych, które często są wąskim gardłem właśnie ze
względu na latency (tam też można do woli skalować horyzontalnie).
baklarz
woooolny zasobożerny w porównaniu z Pythonem nie mówiąc o Javie i trzeba
dostawiać nowe serwerki i przepisywać ...
--
Tomasz Drobiszewski
Janusz A. Urbanowicz
Ty patrz, szkoda ze moi współpracownicy tygodniami wymyślający sposoby
na zwiększenie wydajności, tego nie wiedzą.
Marcin Mielżyński
zasobożerny w porównaniu z Pythonem nie mówiąc o Javie i trzeba
> dostawiać nowe serwerki i przepisywać ...
Co do tej pamięci to nieprawda, a to za sprawą bardzo oszczędnego użycia
pamięci dla Fixnum (31 bitów), PyIntObject zjada na dzień dobry 12
bajtów na liczbę! Ze słownikami jest jeszcze gorzej - dla pustego - Ruby
- 20 bajtów, Python 124 bajtów!
Dlatego też dla średnich aplikacji desktopowych Ruby zjada prawie 2x
mniej pamięci niż Python.
Z tą wydajnością javy to jest też jest mit. Trunk jrubiego już w tej
chwili działa szybciej niż jego implementacja w C dla mikrobenchmarków i
to bez kompilacji do bytecodu (która nb. jest już częściowo
zaimplementowana)
lopex
Robert
Marcin Mielżyński napisał(a):
> baklarz wrote:
>
> zasobożerny w porównaniu z Pythonem nie mówiąc o Javie i trzeba
> > dostawiać nowe serwerki i przepisywać ...
>
>
> Co do tej pamięci to nieprawda, a to za sprawą bardzo oszczędnego użycia
> pamięci dla Fixnum (31 bitów), PyIntObject zjada na dzień dobry 12
> bajtów na liczbę! Ze słownikami jest jeszcze gorzej - dla pustego - Ruby
> - 20 bajtów, Python 124 bajtów!
> Dlatego też dla średnich aplikacji desktopowych Ruby zjada prawie 2x
> mniej pamięci niż Python.
A wydajność czasowa?
> Z tą wydajnością javy to jest też jest mit. Trunk jrubiego już w tej
> chwili działa szybciej niż jego implementacja w C dla mikrobenchmarków i
> to bez kompilacji do bytecodu (która nb. jest już częściowo
> zaimplementowana)
Właśnie sam przyznałeś, że maszyna javy jest wydajna - zastanów
się chwilę. Jako ćwiczenie polecam też dowód, że platforma
języka dynamicznie typowanego nie może być szybsza od dobrze
zaimplementowanego kompilatora języka typowanego statycznie.
BTW. testowałem trochę ostatnio Lua i mi się podoba. Source'y 200k,
po instalacji na win32 jeden exec 500k, śmiga szybciej (w niektórych
przypadkach sporo szybciej) niż cpython. Niestety, natywny threading
tak jak w chyba wszystkich tych dynamicznych językach praktyczne
niezaimplementowany.
Robert
Robert napisał(a):
> po instalacji na win32 jeden exec 500k
skłamałem, w wersji 5.0.2 exec ma dokładnie 192512 bajtów. To się
nazywa minimalizm :)
Marcin Mielżyński
>
> A wydajność czasowa?
>
post wyżej...
>> Z tą wydajnością javy to jest też jest mit. Trunk jrubiego już w tej
>> chwili działa szybciej niż jego implementacja w C dla mikrobenchmarków i
>> to bez kompilacji do bytecodu (która nb. jest już częściowo
>> zaimplementowana)
>
> Właśnie sam przyznałeś, że maszyna javy jest wydajna - zastanów
> się chwilę. Jako ćwiczenie polecam też dowód, że platforma
> języka dynamicznie typowanego nie może być szybsza od dobrze
> zaimplementowanego kompilatora języka typowanego statycznie.
>
Zgadza się, ale Python, Ruby, itp... niewykorzystują nawet połowy myków
ze Strongtalka - mogłyby być dużo szybsze niż dzisiaj. W tej chwili
mocno rozwija się Rubinius - zupełnie inne podejście niż np. pypy.
> BTW. testowałem trochę ostatnio Lua i mi się podoba. Source'y 200k,
> po instalacji na win32 jeden exec 500k, śmiga szybciej (w niektórych
> przypadkach sporo szybciej) niż cpython.
Lua jest super, jest też jit do niej: http://luajit.luaforge.net/
lopex
Robert
Marcin Mielżyński napisał(a):
> Zgadza się, ale Python, Ruby, itp... niewykorzystują nawet połowy myków
> ze Strongtalka - mogłyby być dużo szybsze niż dzisiaj. W tej chwili
true, true. albo wyniki ludzi od Selfa.
> mocno rozwija się Rubinius - zupełnie inne podejście niż np. pypy.
no zobaczymy za ile lat...
> > BTW. testowałem trochę ostatnio Lua i mi się podoba. Source'y 200k,
> > po instalacji na win32 jeden exec 500k, śmiga szybciej (w niektórych
> > przypadkach sporo szybciej) niż cpython.
>
> Lua jest super, jest też jit do niej: http://luajit.luaforge.net/
ten jit to chyba jest w jakiejś wstępnej/niedorobionej fazie, z tego,
co czytałem, ale mogę się mylić. ktoś ma doświadczenia?
Jaroslaw Zabiello
> testowałem trochę ostatnio Lua i mi się podoba.
A jak z bibliotekami? Sa jakies drivery do mysql i mssql czy chociaz odbc?
Robert
Jaroslaw Zabiello napisał(a):
> Dnia 13 Dec 2006 02:51:04 -0800, Robert napisał(a):
>
> > testowałem trochę ostatnio Lua i mi się podoba.
>
> A jak z bibliotekami? Sa jakies drivery do mysql i mssql czy chociaz odbc?
Nie sprawdzałem, szczerze mówiąc średnio mnie to grzeje.
baklarz
liczy się jeszcze czas wykonywania operacji. Co z tego, że
zjada 2 razy mniej pamięci skoro działa często i gęsto 2 razy wolniej
niż Python/Java.
Dla mnie liczy się wydjaność stabilność, Ruby jest na samiutkim końcu.
Piszę/pisałem systemy z >> 3000 req/sek w godzinach szczytu i
Railsy nawet z mongrelem i innymi bajerami chodziły jak g... .
Wierz mi, nie traciłbym 3 mcy na przepisywanie aplikacji do ejb3.
--
Tomasz Drobiszewski
Jaroslaw Zabiello
> Railsy nawet z mongrelem i innymi bajerami chodziły jak g... .
Trzeba bylo uzyc nie jednego mongrela ale przynajmniej z 20 monreli z load
balancingiem i szybkim serwerem http na froncie, np. nginx czy cherokee.
> Wierz mi, nie traciłbym 3 mcy na przepisywanie aplikacji do ejb3.
Nie prosciej bylo do Pythona? Pylons + memcache + SQLAlchemy + myghty
templates (z ich wew. mechanizmem cache) powinien byc calkiem szybki.
Pewnie nie trwaloby to 3 miesiace.
Marcin Mielżyński
Ruby jest tragicznie wolny. Zużycie pamięci to nie wszystko
> liczy się jeszcze czas wykonywania operacji. Co z tego, że
> zjada 2 razy mniej pamięci skoro działa często i gęsto 2 razy wolniej
> niż Python/Java.
Nie rozumiem o co chodzi, przecież nie negowałem tego z poprzednim
poście, dlaczego się powtarzasz ?. A z drugiej strony pythona do javy
nie przyrównuj bo to jest rząd wielkości różnicy w wydajności.
> Wierz mi, nie traciłbym 3 mcy na przepisywanie aplikacji do ejb3.
>
W javie jest coraz lepiej, spójrz choćby na frameworki seam (warstwa
trwałości oparta na ejb3 prawie za darmo), czy też roma (dużo lżejszy,
oparty na springu, jpox, echo i jetty).
lopex
Robert
Jaroslaw Zabiello napisał(a):
> Dnia Wed, 13 Dec 2006 12:32:18 +0000 (UTC), baklarz napisał(a):
>
> > Railsy nawet z mongrelem i innymi bajerami chodziły jak g... .
>
> Trzeba bylo uzyc nie jednego mongrela ale przynajmniej z 20 monreli z load
> balancingiem i szybkim serwerem http na froncie, np. nginx czy cherokee.
Słuchaj, sprzęt kosztuje. Powierzchnia i prąd w serwerowni też
kosztują. Racki też kosztują. Serwis też kosztuje. To nie jest tak,
że każdą aplikację bardziej się opłaca rozłożyć na 20 skrzynek
zamiast zoptymalizować na 1. Szczególnie, jeśli trwa to tylko 3
miesiące. Policz - 3 miesiące nawet razy 15 tysięcy miesięcznie
(wątpie, aby wielu ludzi w tej branży w Polsce aż tyle zarabiało)
to 45 tysięcy jednorazowego wydatku. 20 serwerów to co najmniej tyle
samo jednorazowo, plus bardzo duże koszty utrzymania.
> > Wierz mi, nie traciłbym 3 mcy na przepisywanie aplikacji do ejb3.
>
> Nie prosciej bylo do Pythona? Pylons + memcache + SQLAlchemy + myghty
> templates (z ich wew. mechanizmem cache) powinien byc calkiem szybki.
> Pewnie nie trwaloby to 3 miesiace.
Powinien. Jakieś konkretne dane żeby poprzeć tą opinię? A co,
jeśli, powiedzmy, po 1.5 miesiąca okazało się, że ciągle
potrzeba, może nie 20, ale 10 serwerów?
Daniel Mróz
Jaroslaw Zabiello <hipert...@gmail.com> napisał(a):
> Django mądrze zrobili, że od początku (otwarcia kodu) skupili się na
> dokumentacji online. I słusznie. Bo jak ludzie nie mają dobrej
No właśnie. Tylko dlaczego on-line? Żeby zajrzeć do dokumentacji trzeba
mieć dostęp do Internetu. Jakiś taki dziwny trend ostatnio się rodzi.
Pozdrawiam
Beorn
--
Daniel 'Beorn' Mróz <be...@alpha.pl> http://127.0.0.1/beorn
[GIT d s:- a-@ C++++ UL++++$ P+ L++++ E--- W+ N+++ o? K- w---]
[O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*]
[ r(-) y+ ]
baklarz
> Ruby jest tragicznie wolny. Zużycie pamięci to nie wszystko
>> liczy się jeszcze czas wykonywania operacji. Co z tego, że
>> zjada 2 razy mniej pamięci skoro działa często i gęsto 2 razy wolniej
>> niż Python/Java.
>
> Nie rozumiem o co chodzi, przecież nie negowałem tego z poprzednim
> poście, dlaczego się powtarzasz ?. A z drugiej strony pythona do javy
> nie przyrównuj bo to jest rząd wielkości różnicy w wydajności.
>
zajmuje mniej pamięci na obiekty jest wolny.
Co do Pythona masz rację to jest rząd różnicy wolniejszy.
>
>> Wierz mi, nie traciłbym 3 mcy na przepisywanie aplikacji do ejb3.
>>
>
> W javie jest coraz lepiej, spójrz choćby na frameworki seam (warstwa
> trwałości oparta na ejb3 prawie za darmo), czy też roma (dużo lżejszy,
> oparty na springu, jpox, echo i jetty).
>
> lopex
3 m-ce.
Robi się NTG.
--
Tomasz Drobiszewski
Piotr Dembiński
[...]
> Akurat książka online to jest bardzo dobry pomysł.