W dniu 2011-03-13 09:10, Sebastian Biały pisze:

> Przemysł != automatyka. Przemysłem jest też drukowanie faktur.

No więc w kontekście tego co napisałeś Delphi ma się dobrze w przemyśle :)

> Kod pośredni nie ma nic wspólnego z metaprogramowaniem. Co ciekawe chyba
> w 2009 coś tam w Delphi dłubano przy genarykach ale nie wiem z jakim
> skutkiem. Na pewno skutek to żaden dla dydaktyki.

Generyki w Delphi mają się bardzo dobrze. To o czym piszesz było dwie
wersje temu. Pierwszą w której to wprowadzili.

> Delphi jest nieprzenośny z definicji. C/C++ z głupoty.

To podaj tę definicję bo jej nie znam. I odnieś to w praktyce do XE2.

> Cały czas rozmawiamy w kontekście dydaktyki. Interesuje mnie wsparcie w
> postaci pieryliarda rozwiązanychproblemów.

Naprawdę? Zapomniałem bo skręciłeś na wykorzystanie przemysłowe. To
chyba ma się nijak do dydaktyki?

> Jeśli to jest istotne dydaktycznie to poponuje COBOLa.

No i bardzo dobrze.

> Jeśli piszesz logikę typu "onclikc() { sql.execute() }" to faktycznie.
> Jesli potrzebujesz obrobić dane *nie* sqlem to już by się przydało.

Dla dużego procenta standardowych rozwiązań jest to wystarczające.

> Zwiechy podczas zwalniania formy z steka przycisków jakoś nie stanowią
> problemu dla usera bo to nie są aplikacje *real* time.

No to co wygadujesz że z powodu że Delphi nie ma GC nie można używać go
do aplikacji real time.

> Z pamiętnika managera:
> Mamy 40 developerów znających się na Delphi.
> a) zwalniamy wszystkich i zatrudniamy studentów pisząc w C#
> b) męczymy się w Delphi bacznie patrząc ko będzie jutro właścicielem
> Co wybrać, hmmm ...

Typowe polskie podejście :/ Jak zaoszczędzić 5 złotych jeśli już wydało
się 5000.

ad a. I po pół roku zwijamy manatki, bo owi studenci nie potrafią nic
poza pobieraniem pensji, albo wykonanie oprogramowania jest takiej
jakości, że nie nadają się do wdrożenia
ad b. A czemu niby mają się męczyć? O jakich zmianach właściciela piszesz?

> Bo delphi to taki soft do pisania onklików. Jakiekolwiek "wypasione"
> algorytmy kosztuja pieniądze. Mocno to dydaktyczne.

O właśnie. Czekałem na ten koronny argument. Wskazuje on na kilka spraw.
Po pierwsze - nie masz zielonego pojęcia o czym piszesz. Gdzieś coś
słyszałeś ale do końca nie wiadomo co.
Po drugie. To że coś jest możliwe (on cliki) nie znaczy że jest jedynym
rozwiązaniem. Myślenie mochera - jak wprowadzimy ustawę liberalizującą
aborcję to będą z pistoletem przy skroni zmuszać kobiety do dokonywania
aborcji.
Po trzecie - zarabiasz pieniądze pracując na danym środowisku,
wykorzystując wykonaną przez kogoś pracę, to warto chyba im za to
zapłacić? Czy może pracujesz za uznanie i żywisz się energią kosmiczną?
Przypomina mi się pewien dowcip: Syn rozmawia z Bilem G.: Tato jak
zaciągnąć dziewczynę do łóżka? On odpowiada: Kupić wielki bukiet
kwiatów, dobrego szampana, zamówić limuzynę i zaprosić na wykwintną
kolację a później do dobrego hotelu. Tutaj wtrąca się córka: Tato a co z
kwiatami zbieranymi na łące, spacerami brzegiem morza o zachodzie
słońca, recytowaniem wierszy? Na to ojciec: Etam, to wymyślili
linuksiarze żeby po dupczyć za darmo.

Ogólnie widzę że masz wiedzę ogólnikową z zakresu Delphi żeby o nim
dyskutować. Jeśli pojawi się z Twojej strony coś merytorycznego to
śmiało, ale do tego czasu dla mnie EOT.

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

do góry

Sebastian Biały wrote:

>> Co jest głupiego w stosowaniu funkcjonalności specyficznej dla systemu
>> operacyjnego?
>
> Nic. O ile mądrze to zaprojektujesz chowając je za abstrakcją. Jesli
> natomiast jesteś głupi i powciskasz wszedzie np MFC w logikę biznesową
> to nic nie uratuje takiej aplikacji.

Co innego używanie uwiązanego do systemu frameworka, przez co cały program
jest do systemu uwiązany, a co innego używanie specyficznych dla systemu
funkcji, kiedy uwiązane są tylko niewielkie fragmenty.
Jeśli nie widzę w najbliższej przyszłości sensu przenoszenia programu na
inną klasę systemów, to używam wprost funkcji systemowych, a nie używam
żadnych abstrakcji, bo po co mam sobie psuć projekt nadawaniem nowych nazw
do znanych funkcji. Wywołania systemowe dla osób znających dany system są od
razu zrozumiałe; abstrakcje - tylko dla ich autora.

do góry

On Thu, 10 Mar 2011 20:25:53 -0800 (PST), Mariusz
Marszałkowski<m...@g...com> wrote:
> Jak teraz wyglada uzywanie VB? Ulepszyli cos? Ostatnio
> uzywalem gdy byl w wersji 5 i 6. W wiekszych aplikacjach byla
> to katastrofa, nikt nie umial aplikacji doprowadzic
> do stabilnego dzialania, doslownie nikt.

Pod tym względem nie mam szczególnych doświadczeń, pisałem tylko
proste skrypty testowe.

do góry

W dniu 2011-03-13 13:42, Sebastian Biały pisze:
> On 2011-03-13 12:09, Wit Jakuczun wrote:
>>> tyle małe że mozna je spokojnie embedowac w języku zamiast pisać 10x
>>> większy kod do wymiany danych.
>> Kod do wymiany jest bardzo prosty.
>
> Jeśli wymieniasz PODy.
>
Wymieniane były rekordy. Nie wiem czy to POD czy nie :)

>> A kawałek pisałem w Prologu i napisanie go w .Net byłoby raczej mało
>> sensowne. To nie był mały kawałek.
>
> Pisanie kawalka kodu w Prologu jest na tyle specyficzne że nie wchodzi w
> tematyke wątku. Ja raczej nie widzę potrzeby uzywania *osobnego* języka
> do napisania funkcji komparującej do sortowania w C++. Na tyle osobnego
> ze nalezy pisać interfejsy komunikacyjne, serializacje i kupę śmieci
> zamiast użyć pokracznego ale ładnie działającego "emulatora fukcyjnego"
> na boost::whatever.
>
No oczywiście, że w takim przypadku nie ma to sensu. Ja pisałem o
sytuacji gdy to ma uzasadnienie. Sam pisząc w .Net namiętnie korzystam z
linq i bardzo sobie chwalę.

Użycie tego czy innego języka do napisania kawałka kodu wynikało u mnie
z powodów, o których pisał A.L. Te języki po prostu pozwalały na
zakończenie projektu tzw. "sukcesem". Czyli w skończonym czasie i budżecie.

Zresztą nie tylko Prologa tak używam. Również taki język jak R używam
tam, gdzie jest wygodny, czyli do obliczeń statystycznych.
Swego czasu uczestniczyłem w tworzeniu produktu do prognozowania
szeregów czasowych. Użyliśmy R'a jako języka do tworzenia modeli
prognostycznych. Reszta była napisana w C++. Taki tandem (R+C++) dużo
lepiej się sprawdzał (i nadal się sprawdza) od podejścia, w którym
modele były pisane w C++.

> Jeśli zaś mówisz o systemach rozproszonych to podejście projektowe jest
> na tyle inne że nie ma jak dyskutowac o nim w kontekście dydaktyki
> pierwszego roku programowania.
>
Ale ja nie dyskutuję o dydaktyce. Do uczenia danego paradygmatu
najlepiej skorzystać z języka w pełni wspierającego dany paradygmat.

> Na duzych systemach nie pozwoliłbym sobie na opinie o lepszości C++ nad
> resztą świata z powodu jakiejś pierodły boost::phoenix bo to oczywista
> bzdura.
>
O takich systemach pisałem. Jakoś nie zrozumieliśmy się na początku chyba.

Pozdrawiam,
Wit

do góry

On Sun, 13 Mar 2011 17:49:18 +0100, Wit Jakuczun
<w...@g...com> wrote:

>
>Zresztą nie tylko Prologa tak używam. Również taki język jak R używam
>tam, gdzie jest wygodny, czyli do obliczeń statystycznych.
>Swego czasu uczestniczyłem w tworzeniu produktu do prognozowania
>szeregów czasowych. Użyliśmy R'a jako języka do tworzenia modeli
>prognostycznych. Reszta była napisana w C++. Taki tandem (R+C++) dużo
>lepiej się sprawdzał (i nadal się sprawdza) od podejścia, w którym
>modele były pisane w C++.

Podobnie zreszta w przypadku problemow optymalizacyjnych. Problem
definiuje sie w jezyku specjalizowanym (APML, MOSEL, GAMS, MPL...)
ktory sie podlacza do programu napisanego w dowolnym innym jezyku.

Mam taki jeden program napisany w Javie (programowanie liniowe); ma 8
tysiecy linii i jest totalnie nieelastyczny. Zrobienie jakichkolwiek
zmian w modelu zajmuje kupe czasu. Ten sam problem zaprogramowany w
jezyku MOSEL ma okolo 300 linii. Wydajnosc - taka sama

Rowniez problemy obliczeniowe wygodnie jest programowac w Matlabie czy
Scilabie ktore mozna podlaczyc do czego sie chce (Javy, C, C++ w
szczegolnosci)

A.L.

do góry

On 13/03/2011 11:10, Wit Jakuczun wrote:
> W dniu 2011-03-13 02:02, Andrzej Jarzabek pisze:
>> On 12/03/2011 23:49, Wit Jakuczun wrote:
>>> W dniu 2011-03-13 00:46, Andrzej Jarzabek pisze:
>>>>
>>>> To by było dopiero sprzeczne ze zdrowym rozsądkiem. Samo przeniesienie
>>>> danych wymagałoby o wiele więcej wysiłku, niż zakodowanie tego w C++.
>>> Zakodowanie czego?
>>
>> Kawałka funkcjonalności, który napisałem w stylu funkcyjnym, bo kaurat
>> tak było najwygodniej/najbardziej
>> elegancko/najbezpieczniej/najczytelniej.
> Jak napisałem Sebastianowi, moje doświadczenia są zgoły inne.

Z tego co opisywałeś - o ile dobrze zrozumiałem - gdybym miał tak to
robić, to musiałbym włożyć w to kilkanaście razy więcej roboty, plus
wprowadzić do projektu kilka dodatkowych zależności. Obstaję przy tym,
że w moim przypadku dobrą praktyką było zrobienie tego w C++.

do góry

On Sat, 12 Mar 2011 21:31:59 +0100, "Przemek O." <p...@o...eu>
wrote:

A skoro siedzisz w bieżących wersjach Delphi to mam takie pytanie: jak
wygląda poziom FPC (darmowego kompilatora) do komercyjnego pakietu?
--
Grzegorz Krukowski

do góry

W dniu 2011-03-13 20:38, Andrzej Jarzabek pisze:
> Obstaję przy tym,
> że w moim przypadku dobrą praktyką było zrobienie tego w C++.
No i świetnie.

Pozdrawiam,
Wit

do góry

W dniu 2011-03-13 21:09, Grzegorz Krukowski pisze:
> On Sat, 12 Mar 2011 21:31:59 +0100, "Przemek O."<p...@o...eu>
> wrote:
>
> A skoro siedzisz w bieżących wersjach Delphi to mam takie pytanie: jak
> wygląda poziom FPC (darmowego kompilatora) do komercyjnego pakietu?

Jak dla mnie ich drogi się rozeszły. FPC i Lazarus potrafią wczytywać co
prostsze projektu z Delphi. Na odwrót się nie da. Nowe wersje są już
kompletnie niekompatybilne.
O ile FPC i Lazarus jest przenośnie, to dopiero Delphi XE2 bedzie miało
"kroskompilacje" natywną na Win32, Win64, OsX i linuksa.
Będzie to ciekawostka, ale praktyczne zastosowanie będzie miało raczje
win64. Chociaż może się mylę?
Ogólnie FPC bardziej goni nowinki i standardy innych języków/środowisk.
Delphi jest bardziej produkcyjne i wprowadzają w nim to, co może być
faktycznie przydatne przy tworzeniu systemów, a nie teoretyzowaniu o tym
jak się to powinno robić.
Embarcadero skupia się na dostarczeniu kompletnego środowiska do
programowania. Począwszy od środowiska programistycznego, poprzez
systemu raportowania, zarządzania wersjami, profilowaniem, tworzeniem
baz danych itd itp.

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

do góry

On 13/03/2011 10:50, Sebastian Biały wrote:
> On 2011-03-13 02:57, Andrzej Jarzabek wrote:
>> No ale właśnie piszę - łączenie tego wszysztkiego w tym zastosowaniu
>> jest wadą, bo niepotrzebnie komplikuje język.
>
> Algorytmy sa takie że czasem łaczą rozwiązania optymalne z różnych
> dziedzin.

Co jednak niewiele zmienia w kwestii, czy programowania funkcyjnego
lepiej uczyć na małych językach stricte funkcyjnych, a programowania
proceduralnego na małych językach stricte proceduralnych.

> A klarowniej otrzymasz upychając częśc funkcyjną rozwiązania w język
> niefunkcyjny bądź odwrotnie?

Klarowniej będzie, jeśli studentom uczonym programowania proceduralnego
pokazujesz rozwiązania proceduralne, a nie np. funkcyjne, w momencie
kiedy nie znają podstaw programowania funkcyjnego.

>> nieistotne szczegóły. Lepiej do nauki określonych klass zagadnień
>> stosować małe, proste języki, które dobrze te zagadnienia wspierają bez
>> kompromisów w celu wspierania innych rzeczy.
>
> Co prawda ten fragment można 10x łatwiej napisać lambdą, ale nie możemy
> bo mamy Pascala. Natomiast cała reszta jes spoko.

Przecież nie chodzi o to, żeby napisać łatwiej.

>> No ale przecież masz małe i dobre języki do uczenia rzeczy na przecięciu
>> programowania funkcyjnego i imperatywnego. Np. Scheme.
>
> I np Scala. I 0 wsparcia do Scali i 0 dydaktyków do Scheme. E nie. To
> nie przejdzie.

Nie wiem o jakie wsparcie chodzi, ale chyba nie zamierzasz przyjmować
takiego kryterium "X jest dobrym językiem dydaktycznym" -> "ktoś uczy X
na uczelni w Myciskach Niżnych".

>> A ja mówię o tym, że żeby pisać poezję, najpierw dobrze jest opanować
>> alfabet.
>
> Ten alfabet ma dziury. W C++ też, ale troche mniej.

Do różnych literek masz różne czytanki.

>> Ale przecież ja nie postuluję stosowania Pascala w przemyśle.
>
> To jest podstawowy problem dydaktyki: czy na pewno uczyć rzeczy
> nieprzydatnych w jakiejś częsci czy może niewiele tracąc uczyć
> przydatnych? Zazwyczaj "na drugim roku" należy na kusie C/C++ odkrecać
> sposoby myślenia studenta np. "liczymy od 1" albo "jak wyjść z funkcji".
> Traci się na to sporo czasu.

A według mnie ważna część bycia sensownym programistą to umiejętność
radzenia sobie z takimi pierdołami.

>>> Standardowy Pascal to średniowiecze.
>> I co za problem? Nie nadaje się do nauczenia jak wygląda lista albo jak
>> działa quicksort?
>
> Quicksort tak.
>
> Lista nie bo dostajesz w łeb od razu jakimiś znaczkami "^".

Nie rozumiem, o co chodzi z tymi znaczkami. I czy według ciebie raczej
należy uczyć tego w języku bez "jakichś znaczków '^'" - i jaki to niby
język? Bo chyba nie C++?

> Nie. Ale wyjście w coś bardziej skomplikowanego rezalizuje sie i tak na
> innych jezykach i zazwyczaj są to języki klamrowe. Wiedza o składni
> pascala jest bezużyteczna. A jej wyjaśnienie zajmuje mase czasu.

Wiedza o składni Pascala jest równie bezużyteczna ddla kogoś, kto
programuje w języku klamrowym, co wiedza o tym, jak jest skonstruowana
lista dwukierunkowa, dla kogoś, kto używa std::list czy innego
java.util.LinkedList.

> Jesli faktycznie chcemy wyrzucić skladnie padcala do śmieci to tak
> naprawdę nie ma znaczenia jaki to będzie języki i też nijak na korzyśc
> Pascala nic nie przemawia.

Składnia to szczegół, ale przecież są inne języki o dużych walorach
edukacyjnych o podobnej składni: Modula-2 i Ada.

Ale przede wszystkim chodzi o to, że w ramach nauki dobrze się też
zetknąć z różnymi rozwiązaniami, składniami i "design philosophies".
Uczenie się tego to nie jest strata czasu, nawet jeśli danej składni nie
będzie się używać w praktyce.

do góry