On Sat, 12 Mar 2011 19:36:03 +0100, Jędrzej Dudkiewicz
<j...@n...com> wrote:

>On 03/12/2011 12:42 PM, Grzegorz Krukowski wrote:
>> On Fri, 11 Mar 2011 13:51:02 -0600, A.L.<l...@a...com> wrote:
>>
>>> Niedawno srodowisko zszokowala decyzja MIT aby Scheme zastapic
>>> Pythonem.
>> A można gdzieś poczytać nieco z tej dyskusji, głosy za i przeciw?
>
>Dla mnie największymi przeciw są "duck typing" i istotność białych
>znaków. Pamiętam, jakie miałem problemy na początku programowania z
>klamrami, średnikami i czym tam jeszcze. Gdybym miał wtedy dbać jeszcze
>o różnicę między spacjami a tabami i o wcięcia, to pewnie bym jednak
>skończył tę filologię klasyczną...

Wiesz co, mi kiedyś też się wydawało że to może być problem. Tylko jak
sobie przypomniałem absolutne początki z Logo, to:
* nie miałem pojęcia jak działa komputer, co to procesor, pamięć i
tym podobnych ,,niezbędnych'' szczegółów;
* wprowadzenie było proste, nieskomplikowane, na żywo;
* język nie przeszkadzał, tj. po podaniu minimum wiadomości dało się
pisać program;
* bardzo łatwo wymyślało się coś nowego, a jak okazało się to
niemożliwe do realizacji to nauczyciel mówił, a tu masz to i to,
napisz tak i tak i działało!
* programy były oczywiście bardziej ,,graficzne'', żółw to podstawa.

Widać dzieci i laicy w komputerach myślą inaczej niż osoby świadome
działania. Tak więc warto posłuchać opinii tych którzy wbrowadzają w
programowanie kompletnych laików a nie krytykować, bo ja wielki mastah
to od razu zacząłbym od ... To jest jednak zupełnie co innego.
--
Grzegorz Krukowski

do góry

On 2011-03-12 18:42, A.L. wrote:
> Nie, drogi Kolego. Jakies 40 lat temu w dziedzinie makroporcesorow
> robiono rzeczy takie o ktorych makrogeneratorowi C++ zwanemu
> "templates" nawet sie nie sni.

Generatory kodu we wszelakiej postaci mocno odbiegają od tematu wątku.
Ale tak, stosuje sporadycznie. Zaryzykuje że sa słabo związane z
konkretnym językiem.

do góry

On Sat, 12 Mar 2011 19:06:30 +0100, Sebastian Biały
<h...@p...onet.pl> wrote:

>> Po drugie nie ma presji na wprowadzenie tego w niszy którą zajmuje
>> Pascal.
>
>Słusznie. Konserwacja starego kodu nie wymaga nowych ficzerów.

W tej chwili już masz rację.


>>>> I mam nadzieję że nie twierdzisz, że C++ jest superprzenośny?
>>> A jest w ogóle taki jezyk? Ale tak żeby był przenośny z Cray na mój
>>> zegarek naręczny. Oh wait, C/C++ ...
>> Gdyby babcia miała wąsy, to .... Praktyka temu przeczy
>
>Pisuję zarówno na większe systemy (w tym rozproszone) jak i na
>mikrokontrolery "z zegarków". Pomimo że należy się narzeźbić to
>paradoksalnie jezyki "przenośne" jak Java/C# na tych skrajnych
>platformach nie mają co szukać. C/C++ jest niestety przenośny choć
>racja, nie bez rzeźby. Ale w ogóle działają na egoztycznych
>architekturach w przeciwieństwie do reszty pasudo-przenośnego świata.
>Pomijam języki skryptowe z premedytacją ze względu na ich czesto śmiesze
>wydajności i ograniczone zastosowania.

A nie wydeje ci się że jest to tylko i wyłącznie efekt założeń
projektowych języka? Cpochodne nie zakładają nic. Pascal już więcej,
tak więc jak przeniesiesz go na ,,dziwną'' architekturę możesz mieć
większy problem z samym językiem. W jawie masz jeszcze interpeter
ujednolicający środowisko, tyle że na bardzo ,,ciasnych'' i
egzotycznych architekturach to może być po prostu za duże lub za
wolne. Zysk z VM może być dopiero widoczny od pewenej mocy
obliczeniowej i dostępnych zasobów, poniżej po prostu sama VM się nie
zmieści.

>"Zostań projektantem elektroni atomowych w tydzień (dla opornych)."
>
>Może lepiej z daleka od takich książek. Ale przyznaje: mając w reku ze 4
>do Delphi w jednej (!) autor niesmiało zająknął się o hash-mapie. Reszta
>uznala że wszelkie problemy świata rozwiązuje skutecznie operator
>[index]. Jaki język tacy potem programiści.
No to ja spotkałem. Zresztą każda rozsądna pozycja nie będąca opisem
języka jest OK.
--
Grzegorz Krukowski

do góry

On 2011-03-12 20:50, Grzegorz Krukowski wrote:
>> racja, nie bez rzeźby. Ale w ogóle działają na egoztycznych
>> architekturach w przeciwieństwie do reszty pasudo-przenośnego świata.
>> Pomijam języki skryptowe z premedytacją ze względu na ich czesto śmiesze
>> wydajności i ograniczone zastosowania.

> A nie wydeje ci się że jest to tylko i wyłącznie efekt założeń
> projektowych języka? Cpochodne nie zakładają nic. Pascal już więcej,
> tak więc jak przeniesiesz go na ,,dziwną'' architekturę możesz mieć
> większy problem z samym językiem.

Brak założeń to jest dopiero katastrofa. Przypominam że w C nie wiadomo
ile bitow ma int. Ba, nie wiadomo ile bitów ma char ... A mimo to jest
najszerzej kompilowalnym językiem na wszelakiej maści wynalazkach. Jak
to możliwe że taki gówniany język jest aż tak przenośny? A warto
wiedzieć że np. avr-gcc ma switcha pozwalającego zredukować sizeof(int)
== sizeof(char). To dopiero fajna zabawa.

> W jawie masz jeszcze interpeter
> ujednolicający środowisko, tyle że na bardzo ,,ciasnych'' i
> egzotycznych architekturach to może być po prostu za duże lub za
> wolne.

Jave mozna znaleźć nawet na maleństwach z kilkoma kB ROM:

http://www.harbaum.org/till/nanovm/index.shtml

Fakt, za wolne. Ale mimo że np. ARM ma/miał wsparcie częsciowo sprzetowe
(Jazelle) jakoś sie nie sprawdziło. Java nie ma co konkurować z C/C++ w
przenosności. C# nie jest przenosny z definicji bo jak na razie mono ma
status "za pół roku". Coś jeszcze z wazniejszych języków? Chyba reszta
to szum statystyczny.

> Zysk z VM może być dopiero widoczny od pewenej mocy
> obliczeniowej i dostępnych zasobów, poniżej po prostu sama VM się nie
> zmieści.

8kB ROM w ATMega8 i sie mieści :P

do góry

W dniu 2011-03-12 08:07, Stachu 'Dozzie' K. pisze:

>> Napisz o czymś czego nie ma Delphi, bo na razie tutaj niczego takiego
>> nie widzę. Pamiętaj o jednym, jeśli czegoś nie wiesz, to nie znaczy że
>> to nie istnieje.
>
> AFAIK Delphi ani nie ma zarządzania pamięcią (wybór GC/zliczanie
> referencji),

Jest dla interfejsów

ani nie da się w nim metaprogramować (makra/szablony
> anyone?),

Jak się ma odpowiednią bibliotekę / framework to się da.

raptem jedna firma produkuje to środowisko, a przenośność to
> chyba z Windows 2000 na Windows XP jest.

Delphi, fakt, produkuje jedna firma. Ale jeśli tak to porównajmy to do
VS, też produkuje to jedna firma i przenośność jest podobna. Napiszesz o
.NET i ew. przenośności na MONO, to w Delphi jest Prism i mamy to samo.
Ale oprócz Delphi jest np. FPC które w kilku miejscach jest mniej
rozwinięte od Delphi a w kilku bardziej. Kompiluje na dowolną platformę.
Zresztą nowe Delphi które ma się ukazać w połowie (pod koniec) roku tez
ma mieć kros kompilację na Win32, Win64, OsX, linux i to natywną.

Zresztą powiedzmy sobie szczerze, kod pascala nieodwołujący się do
systemu jest tak samo przenośny jak kod c/c++. I tak samo, kod C/C++
jest tak samo nieprzenośny jeśli się odwoła do specyfiki danego systemu.

--
pozdrawiam,
Przemysław Osmański, SoftSYSTEM
www.soft-system.pl
www.kochamjedzenie.pl - portal dla ludzi którzy kochają jedzenie

do góry

W dniu 2011-03-12 15:31, slawek pisze:
>
> Użytkownik "Przemek O." <p...@o...eu> napisał w wiadomości grup
> dyskusyjnych:ilee21$eph$...@n...onet.pl...
>> Napisz o czymś czego nie ma Delphi, bo na razie tutaj niczego takiego
>> nie widzę. Pamiętaj o jednym, jeśli czegoś nie wiesz, to nie znaczy że
>> to nie istnieje.
>
> Dziedziczenie wielobazowe?

Na szczęście nie ma wprost :) Natomiast jest 'nie wprost'. W każdym
razie można uzyskać taką funcjonalność.

Co do STLa, nie - nie ma. Ale czy musi mieć akurat STLa? Znowu podobna
funkcjonalność można osiągnąć innymi metodami, bibliotekami.

Pytanie tylko, czy teraz porównujemy biblioteki czy sam język?

--
pozdrawiam,
Przemysław Osmański, SoftSYSTEM
www.soft-system.pl
www.kochamjedzenie.pl - portal dla ludzi którzy kochają jedzenie

do góry

W dniu 2011-03-12 07:57, Sebastian Biały pisze:
> a) nie ma sensownego miejsca w przemysle (traci na rzecz głównie Java/C#)

Po pierwsze, Delphi nigdy nie miało sensownego miejsca w przemyśle, bo
nie do tego jest/było stworzone. A sztuczne naginanie jednego języka do
wszystkich możliwych zastosowań jest jak dla mnie czynnikiem wskazującym
brakiem wiedzy.
Po drugie, co masz na myśli przemysł. Ja mam na myśli sterowanie
urządzeniami. Fakt, sterownika w Delphi się nie da napisać. Ale
oprogramowanie do sterowania maszynami to w dawniejszych czasach sam
pisałem, i znam osoby które do dziś się tym zajmują. I na brak pracy nie
narzekają.

> b) brak metaprogramowania (cast hell)

I dobrze. Czym innym jest wynikowy program natywny, a czym innym
kompilowany do kodu pośredniego. Niemniej podobną funkcjonalność osiąga
się w inny sposób.

> c) nieprzenosny

Tak samo jak i C/C++/C$ z VS jeśli odwołuje się do zasobów specyficznych
dla systemu operacyjnego. Nie rób tego w Delphi i też będzie przenosny.

> d) wsparcie spadające asymptotycznie do zera

Jakiś konkret? Bo żaden z poważnych dostawców bibliotek/frameworków,
sterowników dla urządzeń które miały wsparcie dla Delphi nie zrezygnował
z niego. Ba w nowych wersjach powstają nawet nowe rozwiązania o których
do tej pory można było w Delphi pomarzyć.

> e) brak sesnownych biblitek algorytmicznych i struktur danych, wszystko
> trzeba pstrykac ręcznie lub czekać "na następną wersję Delphi za pół roku".

Cienko ze znajomością. Może dlatego, że dla Delphi takie biblioteki
(poważne) są w większości płatne, bo to środowisko komercyjne. A może
właśnie o to chodzi? Że nie ma darmowych?

>>> Efekty: W pascalu nie ma mapy, listy. Wynik: Pascalowcy rozwiązuja
>>> wszelkie problemy na tablicach. Taaaak, tablice są najlepsze, po h...
>>> komu jakieś kontenery i abstrakcje w języku.

Tak zgadzam się, domyślnie nie ma. Poprzez biblioteki - ma.

> Na sąsiedniej grupie zapytalem (bez złych intencji, naprawdę miałem
> potrzebe użyć) gdzie znajdę mapę we wspólczesnym Delphi ... okazalo się
> że jestem tępym kretynem bo array jest szybsze.

Nie wypowiadam się. Może faktycznie jest szybsze :P

>> Dla początkujących tak. Więc (posługując się Twoim przykładem) dla
>> każdego bardziej zrozumiałym będzie array of integer niż
>> std::vector<int>.
>
> Nie widze różnicy.
>
>> W pierwszym przypadku wystarczy że przetłumaczy z
>> angielskiego na polski i wie o co chodzi, w drugim już nie jest tak
>> prosto.
>
> Że niby array jest jasne a vector nie?

Ehh, ja teraz też nie widzę różnicy, ale jak wieku temu podchodziłem do
programowania, to dziwnym trafem pascal wydał się łatwiejszy niż c.
Sam vector jest zrozumiały, ale zapis array of integer nawet tłumaczony
z angielskiego na polski już coś znaczy. Konwencja std::vector<int> już
budzi pewne wątpliowści. Np. co to jest ten std, po co dwa dwókropki
itd. itp. To są oczywiste oczywistości, ale jestem bardziej niż pewien,
że osoba która zaczyna będzie miała z tym kłopot.

> Po co ma *nie* być GC? Żeby powstal nastepny milion programów które źle
> zarządzają pamięcią? Pewne klasy problemów można łatwiej rozwiązać z GC,
> co ważniejsze są to problemy występujące częściej (takie jaki GUI, bazy
> czyli domena Delphi). Nikt nie stosuje na poważnie Pascala/Delphi do
> aplikacji np. realtime gdzie zarzadznei pamięcią ma znaczenie. Zazwyczaj
> zorwiązuje się problemy klasy "wystawianie faktur" a w pl "wystawianie
> recept" gdzie GC jest przydatny.

Po pierwsze, jeśli by tworzyć oprogramowanie zgodne z koncepcją RAD to
GC nie jest potrzebne, bo nie licząc wywalenia się programu nie ma
możliwości żeby coś gdzieś wyciekło.
Po drugie, jeśli komuś przestaje to wystarczać, to znaczy że dorósł do
poważnego programowania i wtedy już ma pojęcie co i gdzie może mu wyciekać.
Dla Twojej informacji, Delphi się nie stosuje w aplikacjach typu real
time nie dlatego że nie ma GC, ale dlatego, że aplikacje są uruchamiane
na systemu Windows, który z założenia nie może być stosowany w
aplikacjach tego typu.
Zresztą samo GC nie jest żadnym rozwiązaniem, a w sumie to jest większym
problemem. Nie wiem czy pamiętasz jak pojawił się .NET. Z wielkim hura
skoczyliśmy do pisania aplikacji w tym czymś. I co się okazało, że
aplikacje mają zwiechy w dowolnym momencie, trwające zauważalny czas. Co
było przyczyną? Ano - słabe komputery, windows 98SE i nieszczęsne
zwalnianie zasobów przez GC.

Mówisz, że w Delphi robi się problemy typu "wystawianie faktur". Może
zaciekawi Cię, że firma notowana na WIG20 ma cały system obsługujący
całą firmę produkcyjną. I to system nowy, a nie rozwijany od lat. I ma
możliwość modyfikacji samego siebie i to w trakcie pracy. I jeszcze
wiele możliwość których jak twierdzisz w wymierającym języku nie da się
zrealizować.

> Ile procent w skali rynku? Bo ja ostatnio widzialem bardzo dużo
> programów napisanych w AtariBASICu na jakiejś starej kasecie, jeśli Cię
> to intertesuje.

Rynku całościowego - nie mam pojęcia, nie jestem statystykiem. Ale,
jeśli chodzi o konkretne zastosowania to mam większe pojęcie.

>> nie było, że to oprogramowanie do wystawiania recept, to o czym pisze
>> steruje tomografami, rezonansami, służy do diagnostyki obrazowej, badań
>> przesiewowych itd itp.
>
> Zupełnie jak oprogramowanie napisane w C++, Javie, C#. Lisp na ten
> oprzykład lata w kosmos. W dodatku miałem okazję rozmawiać z programista
> który popełnił fragment sterownika do rezonanu magnetycznego w ...
> VisualBasicu.

No i? Przecież to Ty starasz się udowodnić że w Delphi się już nic nie
pisze, a teraz wypisujesz że zupełnie jak pisane w C++, Javie itd. To w
końcu jak jest?

Ja nie muszę niczego udowadniać, nie mam w tym żadnego interesu. Ba jako
programista Delphi w niszowej dziedzinie jest nawet niewskazane żebym
popularyzował Delphi jako język/środowisko. Im mniej jest programistów
Delphi (dodatkowo znających specyfikę danej dziedziny) tym ja mam
większe zarobki. A firmy nie przeniosą się na inne
platformy/języki/środowiska skoro mają kompletną bazę, doświadczenie i
zainwestowane grube pieniądze.

> Trzeba mieć minimalną wiedzę statystyczną. A ponieważ nikt nie posiada
> obiektywnej musimy bazować na subiektywnych opiniach.

Też nikt nie sili się na sugerowanie że jego opinia jest obiektywna. Ty
dajesz swoją wiedzę, ja częściowo Cie wyprowadzam z błędu i być może
skorygujesz Ty swoją wiedzę w danym temacie, a być może i po części ja.

> Na początek pokazał bym std::sort. Dzieki temu statystycznie więcej osób
> będzie w stanie napisać wydajny kod zamiast pisać popsute implementacje
> bubble sort za każdym razem. Co nie przeszkodzi idiotom i tak spieprzyć,
> ale przynajmniej nie sortowanie.

To zależy, można dać rybę, a można dać wędkę. Nie uważam, żeby wszystko
trzeba było pokazywać na poziomie implementacji, trzeba uczyć
wykorzystywać w pełni posiadane narzędzie wraz ze wszystkimi jego
dobrodziejstwami. Jednak na początku należy pokazać na czym to polega.
Zresztą w takim razie, po co uczyć teorii, wszystkie podstawowe rzeczy
są już zaimplementowane w odpowiednich bibliotekach.
W Delphi też można użyć odpowiednią bibliotekę i wykonać po prostu sort,
bez konieczności jego implementacji.

> PS. Gdzie sa studenci który na studiach z informatyki, w szczególności
> kierunkach dla programistow nie siedzieli jeszcze przed edytorem kodu? Z
> mojej obserwacji wynika że to szum statystyczny.

Oj... Na studia robiłem już w XXI wieku (bo wcześniej mi się nie
chciało, nie miałem potrzeby, czasu i tona innych wymówek). Więc na moim
roczniku i trybie zaczynało 300 parę osób (politechnika) a skończyło
jakieś 25-30? Jak dla mnie to oddaje poziom osób studiujących
programowanie. To chyba raczej nie jest szum statystyczny.

--
pozdrawiam,
Przemysław Osmański, SoftSYSTEM
www.soft-system.pl
www.kochamjedzenie.pl - portal dla ludzi którzy kochają jedzenie

do góry

On 12/03/2011 18:36, Jędrzej Dudkiewicz wrote:
> On 03/12/2011 12:42 PM, Grzegorz Krukowski wrote:
>> On Fri, 11 Mar 2011 13:51:02 -0600, A.L.<l...@a...com> wrote:
>>
>>> Niedawno srodowisko zszokowala decyzja MIT aby Scheme zastapic
>>> Pythonem.
>> A można gdzieś poczytać nieco z tej dyskusji, głosy za i przeciw?
>
> Dla mnie największymi przeciw są "duck typing"

Scheme też ma duck typing, nie?

do góry

W dniu 2011-03-12 19:29, Andrzej Jarzabek pisze:
>> To jest, Kolego, zwyciestwo technologii nad zdrowym rozsadniem.
>> Idobra praktyka
>
> To co w takiej sytuacji byłoby zgodne ze zdrowym rozsądkiem?
Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać w języku
funkcyjnym. Albo kawałek programowania w logice w języku, który to
wspiera, np. w prologu.

Pozdrawiam,
Wit

do góry

On Sat, 12 Mar 2011 19:32:32 +0100, Jędrzej Dudkiewicz
<j...@n...com> wrote:

>On 03/12/2011 06:42 PM, A.L. wrote:
>> On Sat, 12 Mar 2011 17:54:03 +0100, Sebastian Biały
>> <h...@p...onet.pl> wrote:
>>
>>> Przyklady Javay i C# pokazują że jest istotnie różna. Ale co tu gdybać.
>>> Jak ostatnio sprawdzałem to nie było w Pascalu. Coś mi się wydaje że
>>> konstrukcja super-szybkiego kompilatora troche to utrudnia ...
>>
>> Nie, drogi Kolego. Jakies 40 lat temu w dziedzinie makroporcesorow
>> robiono rzeczy takie o ktorych makrogeneratorowi C++ zwanemu
>> "templates" nawet sie nie sni.
>
>Są w użyciu języki, które z tego korzystają? Poza LISPem, w którym można
>robić bardzo potworne rzeczy z makrami?
>
>JD

ta dzialka wyshla z przyczyn dla mnie neijasnych, mimo ze znam dosyc
dobrz ehistorie tej dzialanosci...

No, ale oprocz Lispu w ktorym makra sa jakie sa, to "wzorce" C++ to
nic innego jak zaawansowane makra, troche w stylu takim jakie sie
robilo dla PAscala.

A.L.

do góry