Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #33607 > unrolled thread
| Started by | "M.M." <mmarszik@gmail.com> |
|---|---|
| First post | 2019-12-19 18:26 -0800 |
| Last post | 2020-01-05 10:18 -0800 |
| Articles | 9 on this page of 69 — 6 participants |
Back to article view | Back to pl.comp.programming
Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2019-12-19 18:26 -0800
Czemu Python jest jaki jest? godek.maciek@gmail.com - 2019-12-19 22:39 -0800
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2019-12-19 22:57 -0800
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2019-12-19 22:59 -0800
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2019-12-20 00:28 -0800
Re: Czemu Python jest jaki jest? Roman Tyczka <noemail@because.no> - 2019-12-20 12:43 +0100
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2019-12-20 06:54 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2019-12-30 07:26 +0100
Re: Czemu Python jest jaki jest? Roman Tyczka <noemail@because.no> - 2019-12-30 21:39 +0100
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2019-12-30 23:46 +0100
Re: Czemu Python jest jaki jest? Roman Tyczka <noemail@because.no> - 2020-01-02 13:15 +0100
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-02 18:16 +0100
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-02 20:45 +0100
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 00:20 +0100
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-03 02:02 +0100
Re: Czemu Python jest jaki jest? Roman Tyczka <noemail@because.no> - 2020-01-03 09:15 +0100
Re:Czemu Python jest jaki jest? slawek <x.y@org.org> - 2019-12-30 07:08 +0100
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-02 01:42 +0100
Re:Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-02 09:46 +0100
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-02 20:30 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-02 12:58 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 00:35 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 04:04 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 18:12 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 09:32 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 19:17 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 11:32 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 21:22 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 12:39 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 01:15 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 16:23 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 09:26 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 00:50 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 10:51 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 02:13 -0800
Re: Czemu Python jest jaki jest? fir <profesor.fir@gmail.com> - 2020-01-04 04:39 -0800
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 06:48 -0800
Re: Czemu Python jest jaki jest? fir <profesor.fir@gmail.com> - 2020-01-04 07:09 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 18:40 +0100
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 19:02 +0100
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-04 10:33 -0800
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-03 20:47 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 12:27 -0800
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-04 00:32 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 15:55 -0800
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-04 02:32 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 00:08 -0800
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-04 22:03 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 14:18 -0800
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-05 02:45 +0100
Re: Czemu Python jest jaki jest? fir <profesor.fir@gmail.com> - 2020-01-05 00:39 -0800
Re: Czemu Python jest jaki jest?b J-23 <Baczeklu@poczta.fm> - 2020-01-05 23:15 +0100
Re: Czemu Python jest jaki jest?b godek.maciek@gmail.com - 2020-01-05 15:30 -0800
Re: Czemu Python jest jaki jest?b J-23 <Baczeklu@poczta.fm> - 2020-01-06 01:40 +0100
Re: Czemu Python jest jaki jest?b godek.maciek@gmail.com - 2020-01-06 02:12 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-05 10:25 +0100
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-06 02:34 -0800
Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-05 15:59 -0800
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-02 12:51 -0800
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 01:18 +0100
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-02 19:40 -0800
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-09 04:57 -0800
Re:Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 10:04 +0100
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-03 20:56 +0100
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 09:31 +0100
Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-04 22:18 +0100
Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 23:48 +0100
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-05 10:33 -0800
Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-05 10:18 -0800
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2020-01-02 19:40 -0800 |
| Message-ID | <46ee752c-74fb-45a1-ae3f-60ba7a92f7e2@googlegroups.com> |
| In reply to | #33649 |
On Friday, January 3, 2020 at 1:18:08 AM UTC+1, slawek wrote:
> "M.M." <m@g.c> Wrote in message:
> > Podobno główną zaletą Pythona jestto, że po zaledwie małym kursie można szybko pisać duże aplikacje. W C++bez solidnego kursu i praktyki programować się zdecydowanie nie da. Czasami tu iówdzie można przeczytać, że Python...
>
>
> 1. IMO Python jest niezbyt dobry dla programów mających ponad
> 100000 LOC (nie licząc bibliotek i cudzych modułów).
Często czytałem że większe programy pisane w językach z dynamicznym
typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem
tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?
Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod
warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w jeszcze
innym do milionów?
> Idealnie
> program w Pythonie to jakieś 2000 do 5000 LOC robiące to do czego
> w C++ potrzeba byłoby jakiegoś giganta na pół miliona linii kodu.
Czy na pewno nadal rozmawiamy o języku programowania czy już o
bibliotekach? Pół miliona to 100 razy więcej niż 5tys. W C++
też pisze się efektywnie, ale trzeba mieć odpowiednie biblioteki.
> Oczywiście całkiem konkretne rzeczy da się zrobić w np. 50
> linijkach lub mniej. Przykładowo: zassać dane z bazy, zrobić
> obliczenia i narysować publish-ready wykresy.
W C++ też to można zrobić w 50 linijkach, kwestia bibliotek.
> 2. W C++ da się programować na poziomie C. Tak m.i. programują
> mikrokontrolery elektronicy - udając że nie ma OOP, STL, new i
> nawet const.
Osobiście programowałem w C++ na mikrokontrolery. Dzięki szablonom
miałem prawie od kopa 3 wersje swojej biblioteki, wielkość kodu w
zależności od wersji biblioteki różniła się wielokrotnie, mogłem
wybrać najmniejszy kod. W C bym musiał nieźle się nagimnastykować żeby
uzyskać taki efekt.
> 3. Siłą Pythona jest abstrakcja - patrz niżej:
> def commute(a, b): return a*b - b*a
>
> Dowcip w tym ze definicja commute jest zupełnie ogólna - mogą tam
> być zwkłe int, mogą być macierze, mogą być operatory różniczkowe.
Niby w C++ też, ale zapis jest z lekka rozwlekły:
template< class T >
void compute(T &a, T &b) { return a*b - b*a; }
> W C++ też dałoby się to /jakoś/ zrobić. Tyle że w Pythonie taki
> poziom abstrakcji jest czymś zupełnie normalnym.
Hmmmm to prawda.
> 4. Python ma parę PASKUDNYCH wad.
Ja nie wiem.
Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2020-01-09 04:57 -0800 |
| Message-ID | <7cf3936e-be20-47f5-8e82-a47e4932bc14@googlegroups.com> |
| In reply to | #33649 |
On Friday, January 3, 2020 at 1:18:08 AM UTC+1, slawek wrote: > 1. IMO Python jest niezbyt dobry dla programów mających ponad > 100000 LOC (nie licząc bibliotek i cudzych modułów). Idealnie > program w Pythonie to jakieś 2000 do 5000 LOC robiące to do czego > w C++ potrzeba byłoby jakiegoś giganta na pół miliona linii kodu. > Oczywiście całkiem konkretne rzeczy da się zrobić w np. 50 > linijkach lub mniej. Przykładowo: zassać dane z bazy, zrobić > obliczenia i narysować publish-ready wykresy. Tam nie ma więcej niż 50 linii kodu: https://doc.qt.io/qt-5/qtcharts-linechart-example.html https://doc.qt.io/qt-5/qtcharts-areachart-example.html W przykładach jest jakby mniej. Możliwości też sporo: https://doc.qt.io/qt-5/qtcharts-examples.html Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | slawek <x.y@org.org> |
|---|---|
| Date | 2020-01-03 10:04 +0100 |
| Message-ID | <qun02d$i3d$1@news.icm.edu.pl> |
| In reply to | #33607 |
"M.M." <m@g.c> Wrote in message:
>Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?
Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod
warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w
jeszcze innym do milionów?
Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.
10, może 30 programistów. Czyli trzeba mieć 10 programistów
doskonale znających Pythona, trzymających jeden standard
kodowania, zdyscyplinowanych i nie przeszkadzających sobie
wzajemnie. Ok. Tyle że Python nie ma narzędzi zmuszających do
zachowania porządku. Nie "pomagających" - ale właśnie
zmuszających.
Czy na pewno nadal rozmawiamy o języku programowania czy już o
bibliotekach? Pół miliona to 100 razy więcej niż 5tys. W C++ też
pisze się efektywnie, ale trzeba mieć odpowiednie
biblioteki.
W C++ też to można zrobić w 50 linijkach, kwestia bibliotek.
Owszem. Ale dla C++ nie ma PyPI - repozytorium ogólnie dostępnych
bibliotek z sensowną licencją. Prosty przykład - w Pythonie jest
matplotlib - a w C++ jest... No właśnie, nie ma czegoś
takiego.
3. Siłą Pythona jest abstrakcja - patrz niżej:
def commute(a, b): return a*b - b*a
Dowcip w tym ze definicja commute jest zupełnie ogólna - mogą tam
być zwkłe int, mogą być macierze, mogą być operatory różniczkowe.
Niby w C++ też, ale zapis jest z lekka rozwlekły:
template< class T >
void compute(T &a, T &b) { return a*b - b*a; }
Niezupełnie. Powinno być:
template<class Ta, class Tb, class T>
T compute(Ta a, Tb b) { return a*b - b*a; }
Ups, klasa T jest nieustalona
4. Python ma parę PASKUDNYCH wad.
a. Brak odporności na inżynierię odwrotną.
b. Brak sensownej wielowątkowości. Patrz GIL.
c. Ogromny rozmiar exe - dla hello world to około 30 mega.
d. Czasami 1000 wolniej działa niż to samo w C++.
e. Totalnie olane kwestie bezpieczeństwa.
f. Problematyczna implementacja niektórych operacji wbudowanych w
sam język.
[toc] | [prev] | [next] | [standalone]
| From | J-23 <Baczeklu@poczta.fm> |
|---|---|
| Date | 2020-01-03 20:56 +0100 |
| Message-ID | <5e0f9c78$0$550$65785112@news.neostrada.pl> |
| In reply to | #33654 |
W dniu 03.01.2020 o 10:04, slawek pisze: > "M.M." <m@g.c> Wrote in message: > >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie? > Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod > warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w > jeszcze innym do milionów? > > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np. > 10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów. Pytam z czystej ciekawości Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | slawek <x.y@org.org> |
|---|---|
| Date | 2020-01-04 09:31 +0100 |
| Message-ID | <qupigf$o85$1@news.icm.edu.pl> |
| In reply to | #33661 |
J-23 <Baczeklu@poczta.fm> Wrote in message: > W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod> warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w> jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.> 10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam Na podstawie zebranego doświadczenia. --
[toc] | [prev] | [next] | [standalone]
| From | J-23 <Baczeklu@poczta.fm> |
|---|---|
| Date | 2020-01-04 22:18 +0100 |
| Message-ID | <5e110110$0$520$65785112@news.neostrada.pl> |
| In reply to | #33672 |
W dniu 04.01.2020 o 09:31, slawek pisze: > J-23 <Baczeklu@poczta.fm> Wrote in message: >> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod> warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w> jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.> 10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam > > > Na podstawie zebranego doświadczenia. > Chciałem ci coś innego napisać ale się powstrzymałem :) ale 100 tys LOC kodu przy dziesięciu programistach to jakoś mizernie mało na jednego wychodzi - po 10 tys LOC stąd było pytanie o ramy czasowe bo jak są krótkie to wtedy rozumiem :) Pozdrawiam J-23
[toc] | [prev] | [next] | [standalone]
| From | slawek <x.y@org.org> |
|---|---|
| Date | 2020-01-04 23:48 +0100 |
| Message-ID | <qur4o7$se7$1@news.icm.edu.pl> |
| In reply to | #33684 |
J-23 <Baczeklu@poczta.fm> Wrote in message: > W dniu 04.01.2020 o 09:31, slawek pisze:> J-23 <Baczeklu@poczta.fm> Wrote in message:>> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod> warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w> jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.> 10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam> > > Na podstawie zebranego doświadczenia.> Chciałem ci coś innego napisać ale się powstrzymałem :)ale 100 tys LOC kodu przy dziesięciu programistach to jakoś mizernie mało na jednego wychodzi - po 10 tys LOC stąd było pytanie o ramy czasowe bo jak są krótkie to wtedy rozumiem :)PozdrawiamJ-23 Dwa - trzy miesiące. I drobiazg - kod, testy, dokumentacja itd. Przy założeniu że to nie będzie copy-paste, np takie: A11 = cos(b11) A12 = cos(b12) To wychodzi jakoś tak 3000 linii na miesiąc, czyli około 200 linijek dziennie (odlicz weekendy itp.), czyli 25 linijek na godzinę przy 8 godzinnym dniu pracy. Nie licząc komentarza, dokumentacji, jakichś papierków dla GUS (od 15 pracowników obowiązkowe). Odlicz czas na komunikację pomiędzy programistami, szkolenia, spotkania z tzw. klientem. Dolicz debugowanie. Z reguły co najmniej 50% kodu trzeba będzie pisać dwa razy - jakaś refaktoryzacja, zmiana priorytetów czy bibliotek. Chyba że nastawiamy się na klepanie bezkrytycznie wszystkiego jak leci... byle już nigdy do tego nie wracać. Moim zdaniem wykonalne, ale przy dobrej motywacji i kompetentnych pracownikach. Oczywiście może jesteś szybszy, ale większość ludzi jakich spotkałem, a którzy przechwalali się że "zrobią w weekend", nie potrafiło wytrzymać takiego tempa pracy jakie deklarowali. Albo po prostu robili plagiaty i/lub w inny sposób korzystali z cudzej pracy. Samo zrozumienie dziedziny problemu to mogą być tygodnie - np. gdybym pisał programy do obliczania podatków musiałbym zrozumieć prawo podatkowe danego kraju, może trochę karnego - a być może nawet nie jednego kraju, ale parunastu - na szczęście nie piszę programów księgowych itp. Dlatego całkiem możliwe że tempo byłoby gorsze.
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2020-01-05 10:33 -0800 |
| Message-ID | <7e6c2f72-0501-4089-af71-a594338a936a@googlegroups.com> |
| In reply to | #33686 |
On Saturday, January 4, 2020 at 11:48:40 PM UTC+1, slawek wrote: > J-23 <B@p.f> Wrote in message: > > W dniu 04.01.2020 o 09:31, slawek pisze:> J-23 <B@p.f> Wrote in message:>> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod> warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w> jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.> 10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam> > > Na podstawie zebranego doświadczenia.> Chciałem ci coś innego napisać ale się powstrzymałem :)ale 100 tys LOC kodu przy dziesięciu programistach to jakoś mizernie mało na jednego wychodzi - po 10 tys LOC stąd było pytanie o ramy czasowe bo jak są krótkie to wtedy rozumiem :)PozdrawiamJ-23 > > > Dwa - trzy miesiące. I drobiazg - kod, testy, dokumentacja itd. > Przy założeniu że to nie będzie copy-paste, np takie: > > A11 = cos(b11) > A12 = cos(b12) > > To wychodzi jakoś tak 3000 linii na miesiąc, czyli około 200 > linijek dziennie (odlicz weekendy itp.), czyli 25 linijek na > godzinę przy 8 godzinnym dniu pracy. Nie licząc komentarza, > dokumentacji, jakichś papierków dla GUS (od 15 pracowników > obowiązkowe). Odlicz czas na komunikację pomiędzy programistami, > szkolenia, spotkania z tzw. klientem. Dolicz debugowanie. Z > reguły co najmniej 50% kodu trzeba będzie pisać dwa razy - jakaś > refaktoryzacja, zmiana priorytetów czy bibliotek. Chyba że > nastawiamy się na klepanie bezkrytycznie wszystkiego jak leci... > byle już nigdy do tego nie wracać. > > Moim zdaniem wykonalne, ale przy dobrej motywacji i kompetentnych > pracownikach. Oczywiście może jesteś szybszy, ale większość ludzi > jakich spotkałem, a którzy przechwalali się że "zrobią w > weekend", nie potrafiło wytrzymać takiego tempa pracy jakie > deklarowali. > > Albo po prostu robili plagiaty i/lub w inny sposób korzystali z > cudzej pracy. > > Samo zrozumienie dziedziny problemu to mogą być tygodnie - np. > gdybym pisał programy do obliczania podatków musiałbym zrozumieć > prawo podatkowe danego kraju, może trochę karnego - a być może > nawet nie jednego kraju, ale parunastu - na szczęście nie piszę > programów księgowych itp. > > Dlatego całkiem możliwe że tempo byłoby gorsze. Zgadzam się w całości, nawet dodałbym, że może być znaaaaacznie gorsze, gdy właśnie uwzględnić zrozumienie problemu, optymalizację, testy, przenośność kodu, wersje, refaktoryzację, dynamicznie zmieniające się wymagania klienta.... Ktoś kiedyś pisał, że z uwzględnieniem wersji wychodzą 2 linijki kodu na dobę na programistę. Jeśli zadanie proste, dobrze znane, jeśli projekt mały, to i można 2tys linijek na dobę wklepać z czego 90% interfejs w htmlu. Mi czasami przez tydzień pracy dzień w dzień ubywa linijek kodu, a nawet całych plików, bo po okresie wstępnego-szalonego prototypu wydzielam procedury do wspólnych obliczeń. Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2020-01-05 10:18 -0800 |
| Message-ID | <f146bc47-b133-40f7-aab2-1337b04e2241@googlegroups.com> |
| In reply to | #33684 |
On Saturday, January 4, 2020 at 10:18:10 PM UTC+1, J-23 wrote: > W dniu 04.01.2020 o 09:31, slawek pisze: > > J-23 <B@p.f> Wrote in message: > >> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod> warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w> jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.> 10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam > > > > > > Na podstawie zebranego doświadczenia. > > > Chciałem ci coś innego napisać ale się powstrzymałem :) > > ale 100 tys LOC kodu przy dziesięciu programistach to jakoś mizernie > mało na jednego wychodzi - po 10 tys LOC stąd było pytanie o ramy > czasowe bo jak są krótkie to wtedy rozumiem :) Zależy jak trudny problem. Pozdrawiam
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | pl.comp.programming
csiph-web