> Kod źródłowy sam w sobie faktycznie może mało kogo interesować w czasach
> pokoju - ale fakt jego publicznej obecności oraz możliwość dokonania w
> nim zmian są, dla wielu firm, niezwykle istotne.

Sam tak kiedyś myślałem. I nadal tak uważam w odniesieniu do bibliotek - powinny być
rozprowadzane z kodem.
Natomiast w przypadku pełnych programów (Word, Excel, ...) lub nawet w przypadku
platform sam dostrzegłem, że tego oczekiwania nie przestrzegam. Co więcej, nie
przestrzegam go również w przypadku platform deweloperskich. I to nie tylko tych,
które instaluję na komputerze, ale również tych, których tylko używam (powiedzmy, że
w chmurze, chociaż nie lubię tego określenia).
W tej kategorii mamy w zasadzie wszystko od Windowsa, przez iOS/Android, po
przykładowo AWS, Azure, czy co tam kto lubi i jest teraz modne.

> Optując za rozwiązaniem zamkniętym (niezależnie od tego czy jest płatne
> czy nie), stajemy się zależni od producenta.

Dlatego warto uzależniać się od tych, którzy już udowodnili swoją długofalową chęć
istnienia.

> Jeśli ten za pół roku
> splajtuje

Właśnie po to mu płacimy, żeby nie splajtował.
Zauważ, że w ostatnim czasie o "plajtach" (czy ogólnie: o zakończeniu działalności)
słyszeliśmy w odniesieniu do mniej lub bardziej darmowych serwisów. Właściwie co
chwilę coś się zamyka.

> Nasz projekt umiera

Dlaczego? Dlaczego mój projekt w (przykładowo) Pythonie ma umrzeć tylko dlatego, że
się jego twórcy rozeszli? Mój projekt żyje sobie dalej. Tak samo jak dalej żyją sobie
projekty np. w COBOLu.

Taką natychmiastową tragedią jest natomiast wyłączenie serwisu w chmurze - ale
właśnie dlatego w tej dziedzinie warto (o ile w ogóle warto) wiązać się z tymi,
którzy udowodnili długofalowe działanie. I z tymi, którym płacimy pieniędzmi a nie
jakimś bardziej ulotnym walorem w stylu informacji o swoich gustach.

> Przy rozwiązaniu OSS natomiast możemy w sytuacji kryzysowej zacisnąć
> zęby, zajrzeć w kod i naprawić to, co przestało działać.

A dlaczego coś miało przestać działać skoro działało? Programy w COBOLu cały czas
działają.

> Do tego nie
> zostajemy z problemem sami: inni prawdopodobnie też nadziali się na ten
> sam problem co my i istnieje niezerowa możliwość połączenia sił.

Możliwość jest dokładnie zerowa. Przy dzisiejszej dynamice i dostępności alternatyw
wszyscy rozejdą się każdy w inną stronę, pierwszego dnia. I jeszcze się pokłócą o to,
która alternatywa była lepsza.

Generalnie, retoryka OSS jest mi dobrze znana. Z obu stron:
1. co złego się może stać gdy nie będę używał OSS
2. co dobrego zyskam gdy będę używał OSS

Problem w tym, że o ile 1. jest realny i czasami faktycznie się dzieje, to 2. się nie
dzieje. To jest teoria, która się w sensownej globalnie skali nie dzieje.

Przykład: AdaCore jest producentem kompilatora GNAT (do Ady). To jest OSS. Niestety
nie ma nikogo, kto podjąłby temat dalszego rozwoju tego kompilatora i jeśli AdaCore
się zwinie, to zwinie się cały ekosystem.
Dlatego nie martwi mnie, że Wolfram nie jest OSS. Bo w przypadku fakapu na jedno
wyjdzie. A w praktyce jestem nawet gotów obstawiać, że Wolfram przetrwa dłużej.

--
Maciej Sobczak * http://www.inspirel.com

do góry

> No to taki np. clojure ma na githubie 145 kontrybutorów.

A taki np. Wolfram zatrudnia 800 ludzi. Zapewne nie wszyscy rozwijają Mathematikę,
ale zapewne ci na GitHubie też nie wszyscy regularnie kontrybuują.
Nadal nie widzę przewagi wynikającej z modelu OSS.

> Kultura open-source wytworzyła swoje mechanizmy radzenia sobie z bugami: pull
requesty merge'ują osoby, które wiedzą, czy bug został dobrze naprawiony

Kultura komercyjna wytworzyła swoje mechanizmy radzenia sobie z bugami: bug reporty
implementują osoby, które wiedzą, jak to zrobić dobrze.

Różnica polega na tym, że w modelu komercyjnym istnieje pojęcie czasu reakcji. A w
modelu OSS czas reakcji jest na zasadzie "jak nam się zechce".

Oczywiście można też robić biznes na usługach wsparcia dla OSS - ale ta opcja tylko
potwierdza to, co pisałem wcześniej, że niektórzy wolą zapłacić za rozwiązanie
problemu, niż "mieć dostęp do kodu".

> Nie twierdzę, że "ta właśnie modyfikacja". Twierdzę, że "możliwość wprowadzenia
dowolnej modyfikacji" (albo inaczej: brak ograniczeń w sposobie używania)

Przecież i tak ci co czytali udokumentację używają tak jak trzeba a ci co nie czytali
używają tak jak nie trzeba. OSS jest do tego ortogonalny, zupełnie bez związku.
To jest fikcja, że dzięki OSS użytkownicy robią rzeczy, których nie mogliby robić bez
OSS. To się w żadnej sensownej skali nie dzieje, patrz moja odpowiedź na post
Mateusza.

Zgadza się, po otwarciu kodu do gry Quake niektórzy uruchomili ją na... oscyloskopie.
Są filmiki na YouTube. Ale nie uważam tego zjawiska za dowód na praktyczną wartość
dodaną modelu OSS.

> Wolfram na Tiobe się nie pojawia (nie wiem, czy dlatego, że nie jest indeksowany,
czy dlatego, że nikt go nie używa).

To faktycznie ciekawe. Nie wiem, dlaczego się nie pojawia.

Ale spójrzmy tutaj:

http://demonstrations.wolfram.com/

12000+ przykładowych projektów. To są te *wybrane*.
Same się chyba nie napisały?

Najwyraźniej społeczność użytkowników Wolframa nie bywa na GitHubie. A Tiobe nie bywa
tam, gdzie ta społeczność bywa. A gdzieś bywa, bo inaczej nie powstałyby te projekty
powyżej. Nie mam innego wytłumaczenia.

> > Najpierw miałeś opinię, że trzeba się uczyć Pythona zamiast Wolframa (to pierwszy
post w tej dyskusji).
>
> Wklejenie linka jest równoważne z "posiadaniem opinii"?

A to przepraszam. Będę pamiętał, żeby nie łączyć ze sobą Twoich postów w logiczne
ciągi. :-)

> > Natomiast ciekawym przypadkiem są zastosowania krytyczne,
>
> No jasne, ktoś ma ten kod źródłowy.
> Tylko dlaczego użytkownik ma nie móc go mieć?

Przecież piszę, że użytkownik go ma.
Tylko że to nie jest normalny użytkownik. I założenie jest takie, że normalnemu nie
jest potrzebny. I praktyka właśnie taka jest. Dlatego uważam, że walory OSS są
przereklamowane - normalni użytkownicy nie korzystają z wartości dodanej, jaką ma być
dostępność kodu źródłowego.
I dlatego (zataczając szeroki kwadrat), nie jest problemem, że Wolfram takiego kodu
nie udostępnia.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu czwartek, 20 czerwca 2019 20:33:19 UTC+2 użytkownik Maciej Sobczak napisał:
> > No to taki np. clojure ma na githubie 145 kontrybutorów.
>
> A taki np. Wolfram zatrudnia 800 ludzi. Zapewne nie wszyscy rozwijają Mathematikę,
ale zapewne ci na GitHubie też nie wszyscy regularnie kontrybuują.
> Nadal nie widzę przewagi wynikającej z modelu OSS.
>
> > Kultura open-source wytworzyła swoje mechanizmy radzenia sobie z bugami: pull
requesty merge'ują osoby, które wiedzą, cz
Różnica polega na tym, że w modelu komercyjnym istnieje pojęcie czasu reakcji. A w
modelu OSS czas reakcji jest na zasadzie "jak nam się zechce".

Kto powiedział, że jeżeli firma udostępnia źródła swojego produktu, to produkt nie
może być komercyjny?

> Oczywiście można też robić biznes na usługach wsparcia dla OSS - ale ta opcja tylko
potwierdza to, co pisałem wcześniej, że niektórzy wolą zapłacić za rozwiązanie
problemu, niż "mieć dostęp do kodu".

W porządku. A niektórzy wolą mieć dostęp do kodu.

> > Nie twierdzę, że "ta właśnie modyfikacja". Twierdzę, że "możliwość wprowadzenia
dowolnej modyfikacji" (albo inaczej: brak ograniczeń w sposobie używania)
>
> Przecież i tak ci co czytali udokumentację używają tak jak trzeba a ci co nie
czytali używają tak jak nie trzeba. OSS jest do tego ortogonalny, zupełnie bez
związku.

Nie jest. Przeportowanie albo modyfikacja albo wycięcie fragmentów projektu i
włączenie gdzieś indziej - to też sposoby używania.
Pisanie Pythonowych bindingów do bibliotek w C było jednym z ważniejszych sposobów
używania kodu Pythona.

> To jest fikcja, że dzięki OSS użytkownicy robią rzeczy, których nie mogliby robić
bez OSS. To się w żadnej sensownej skali nie dzieje, patrz moja odpowiedź na post
Mateusza.

No, tyle że np. Python albo PHP to dostępne od ręki kontrprzykłady, że jednak się
dzieje.

> Zgadza się, po otwarciu kodu do gry Quake niektórzy uruchomili ją na...
oscyloskopie. Są filmiki na YouTube. Ale nie uważam tego zjawiska za dowód na
praktyczną wartość dodaną modelu OSS.

Po otwarciu kodu do gry Quake działo się wiele innych rzeczy.
Na przykład wyszedł port na Linuksa. Albo ludzie zaczęli tworzyć różne narzędzia i
mody.

> > Wolfram na Tiobe się nie pojawia (nie wiem, czy dlatego, że nie jest indeksowany,
czy dlatego, że nikt go nie używa).
>
> To faktycznie ciekawe. Nie wiem, dlaczego się nie pojawia.
>
> Ale spójrzmy tutaj:
>
> http://demonstrations.wolfram.com/
>
> 12000+ przykładowych projektów. To są te *wybrane*.
> Same się chyba nie napisały?

Zerknąłem na kilka, i wyglądały jak zaliczeniowe projekty studenckie.
Na stronie MIT Scratch chwalą się, że ichni użytkownicy mają ponad 42 miliony
projektów.
Scratch jest 26 na liście TIOBE.

> Najwyraźniej społeczność użytkowników Wolframa nie bywa na GitHubie. A Tiobe nie
bywa tam, gdzie ta społeczność bywa. A gdzieś bywa, bo inaczej nie powstałyby te
projekty powyżej. Nie mam innego wytłumaczenia.

Repozytorium ciekawe. Właśnie ściągam ponad 1gigową paczkę z "CDF playerem", żeby móc
odpalić. Niektóre dema działają w przeglądarce, a inne nie (te, które działają, robią
to "raczej tak sobie")

> > > Najpierw miałeś opinię, że trzeba się uczyć Pythona zamiast Wolframa (to
pierwszy post w tej dyskusji).
> >
> > Wklejenie linka jest równoważne z "posiadaniem opinii"?
>
> A to przepraszam. Będę pamiętał, żeby nie łączyć ze sobą Twoich postów w logiczne
ciągi. :-)

Może wystarczy, żebyś nie przypisywał mi autorstwa cudzych wypowiedzi.

> > > Natomiast ciekawym przypadkiem są zastosowania krytyczne,
> >
> > No jasne, ktoś ma ten kod źródłowy.
> > Tylko dlaczego użytkownik ma nie móc go mieć?
>
> Przecież piszę, że użytkownik go ma.
> Tylko że to nie jest normalny użytkownik. I założenie jest takie, że normalnemu nie
jest potrzebny.

Skąd takie założenie?

> I praktyka właśnie taka jest. Dlatego uważam, że walory OSS są przereklamowane -
normalni użytkownicy nie korzystają z wartości dodanej, jaką ma być dostępność kodu
źródłowego.

Nie wiem kim mieliby być "normalni użytkownicy".
Komputer to z definicji urządzenie programowalne.

> I dlatego (zataczając szeroki kwadrat), nie jest problemem, że Wolfram takiego kodu
nie udostępnia.

W takim razie co jest problemem?

do góry

> Kto powiedział, że jeżeli firma udostępnia źródła swojego produktu, to produkt
nie może być komercyjny?

Może być (patrz AdaCore/GNAT) - ale nie trzeba udostępniać, żeby był.
Więc Wolfram nie udostępnia.

> Nie jest. Przeportowanie albo modyfikacja albo wycięcie fragmentów projektu i
włączenie gdzieś indziej - to też sposoby używania.

Ale jak zapytałem, gdzie byś chciał przeportować Mathematikę albo co byś chciał
zmodyfikować, to nie chciałeś albo nie umiałeś odpowiedzieć. Więc zakładam, że te
zastosowania są albo już pokryte albo niepotrzebne.

> Pisanie Pythonowych bindingów do bibliotek w C było jednym z ważniejszych sposobów
używania kodu Pythona.

Kod źródłowy Pythona w ogóle nie jest do tego potrzebny.
I jest to raczej standard - Wolframowe bindingi do bibliotek w C też się pisze i też
kod Wolframa nie jest do tego potrzebny.

Gdybyś napisał, że niektórzy włączają interpreter Pythona do programów napisanych w
C, to taki przykład byłby ciekawszy. Ale do tego też kod źródłowy nie jest potrzebny,
wystarczy header. I Wolframa też się tak włącza.

Więc żadne z opisanych przez Ciebie zastosowań nie wymaga dostępności kodu.

> Po otwarciu kodu do gry Quake działo się wiele innych rzeczy.
> Na przykład wyszedł port na Linuksa. Albo ludzie zaczęli tworzyć różne narzędzia i
mody.

Ale Wolfram już na Linuksie jest. A narzędzia i "mody" (cokolwiek by to miało znaczyć
w przypadku Wolframa) pisze się w oparciu o mechanizmy rozszerzania, które nie
wymagają udostępniania kodu.

> > http://demonstrations.wolfram.com/
>
> Zerknąłem na kilka, i wyglądały jak zaliczeniowe projekty studenckie.

Bardzo możliwe, że to *były* projekty studenckie. Studenci to bardzo poważna
(ilościowo przynajmniej) grupa docelowa dla Wolframa.
A chcesz zerknąć na GitHuba? :-D

> Na stronie MIT Scratch chwalą się, że ichni użytkownicy mają ponad 42 miliony
projektów.

Zerknąłem na kilka, i wyglądały jak zaliczeniowe projekty w szkole podstawowej.

I wyobraź sobie, że nawet sobie nie kpię. Bo właśnie po to Scratch powstał.

> Scratch jest 26 na liście TIOBE.

Brawo.

> Repozytorium ciekawe. Właśnie ściągam ponad 1gigową paczkę z "CDF playerem", żeby
móc odpalić. Niektóre dema działają w przeglądarce, a inne nie (te, które działają,
robią to "raczej tak sobie")

Jakąś staroć wybrałeś. :-)

[kod źródłowy]
> > I założenie jest takie, że normalnemu nie jest potrzebny.
>
> Skąd takie założenie?

To założenie pochodzi ze wszystkich innych dziedzin życia.

> Nie wiem kim mieliby być "normalni użytkownicy".
> Komputer to z definicji urządzenie programowalne.

Owszem. Dlatego piszę sobie program w Wolframie. albo w VisualStudio. Albo w PL/SQLu
na Oracle'a. Czyli używam komputera zgodnie z jego definicją. Tak?

> > I dlatego (zataczając szeroki kwadrat), nie jest problemem, że Wolfram takiego
kodu nie udostępnia.
>
> W takim razie co jest problemem?

A coś jest problemem? Gdzie jest napisane, że wszystko ma mieć 100% penetrację rynku?
To tak jakbyś zapytał, dlaczego np. Ferrari nie jest bardziej popularne. No nie jest.
Ale czy to jest problem?

Natomiast gdyby to już miał być problem i gdybym miał szukać jego przyczyn, to
szukałbym w skojarzeniu - Mathematica i/lub Wolfram kojarzą się z matmą, której
większość nie lubi. Python się tak nie kojarzy i być może brak takiego skojarzenia
daje niektórym nadzieję, że nawet jak w szkole nie lubili matematyki, to być może i
tak zostaną programistami. W równoległym wątku o liczbach zmiennoprzecinkowych było
kilka obserwacji na ten temat.

Zauważ też, że istnieją narzędzia OSS, w zakresie szkolnym mające porównywalne
możliwości do Mathematiki - Octave, Maple, etc., a jednak ich popularność wynosi
epsilon. I gdybyś miał rację co do wpływu OSS na popularność czegokolwiek, to Octave,
Maple, etc. by zmiótł Mathematikę z rynku. A jednak nie zmiótł i jak przylecieli
kosmici, to trzeba było Wolframa, żeby się z nimi dogadać (polecam film "Arrival",
polski tytuł "Nowy początek"). Dlatego nadal twierdzę, że bycie OSS nic nie wnosi do
popularności czegoś, co jest kompletnym produktem, bo w konteście kompletnych
produktów użytkownikom kompletnie wisi czy mają dostęp do kodu, czy nie.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu piątek, 21 czerwca 2019 17:02:15 UTC+2 użytkownik Maciej Sobczak napisał:

> > Nie jest. Przeportowanie albo modyfikacja albo wycięcie fragmentów projektu i
włączenie gdzieś indziej - to też sposoby używania.
>
> Ale jak zapytałem, gdzie byś chciał przeportować Mathematikę albo co byś chciał
zmodyfikować, to nie chciałeś albo nie umiałeś odpowiedzieć. Więc zakładam, że te
zastosowania są albo już pokryte albo niepotrzebne.

Dziwna logika stoi za Twoim uzasadnieniem. Coś jak:
"Więźniowie w zakładzie karnym mają spacerniak, więc nie trzeba ich wypuszczać na
wolność, bo przecież mogą sobie tam pospacerować."

> > Po otwarciu kodu do gry Quake działo się wiele innych rzeczy.
> > Na przykład wyszedł port na Linuksa. Albo ludzie zaczęli tworzyć różne narzędzia
i mody.
>
> Ale Wolfram już na Linuksie jest. A narzędzia i "mody" (cokolwiek by to miało
znaczyć w przypadku Wolframa) pisze się w oparciu o mechanizmy rozszerzania, które
nie wymagają udostępniania kodu.

A mówiąc konkretniej, te mechanizmy, które nie wymagają udostępniania kodu, nie
wymagają udostępniania kodu.

> > Repozytorium ciekawe. Właśnie ściągam ponad 1gigową paczkę z "CDF playerem", żeby
móc odpalić. Niektóre dema działają w przeglądarce, a inne nie (te, które działają,
robią to "raczej tak sobie")
>
> Jakąś staroć wybrałeś. :-)

Ale dlaczego to ma mieć znaczenie?

> [kod źródłowy]
> > > I założenie jest takie, że normalnemu nie jest potrzebny.
> >
> > Skąd takie założenie?
>
> To założenie pochodzi ze wszystkich innych dziedzin życia.

No nie wiem.
Na przykład, jak chcę zobaczyć, jak działa odkurzacz, to biorę śrubokręt, rozkręcam i
patrzę sobie, jak działa odkurzacz.
(W samochodach nawet jest specjalna wajcha, która umożliwia użytkownikowi
podniesienie maski i spojrzenie do silnika. W każdym razie kiedyś takie coś było)

> > > I dlatego (zataczając szeroki kwadrat), nie jest problemem, że Wolfram takiego
kodu nie udostępnia.
> >
> > W takim razie co jest problemem?
>
> A coś jest problemem? Gdzie jest napisane, że wszystko ma mieć 100% penetrację
rynku? To tak jakbyś zapytał, dlaczego np. Ferrari nie jest bardziej popularne. No
nie jest. Ale czy to jest problem?

To co innego.
Zeszyty Mathematiki mają potencjał do tego, żeby stanowić medium komunikacji.
Naprawdę bym chciał, żeby tak było.
Na przykład, kiedyś napisałem na Kworze takie coś:
https://www.quora.com/Can-you-teach-me-something-ver
y-easy-about-calculus-right-now/answer/Panicz-Godek

Do zrobienia wykresów użyłem jakiegoś badziewnego programu do grafiki wektorowej. A
chciałbym móc tworzyć interaktywne odpowiedzi, takie jak zeszyty Mathematiki.
I chciałbym też czytać więcej takich odpowiedzi.

do góry

> Dziwna logika stoi za Twoim uzasadnieniem. Coś jak:
> "Więźniowie w zakładzie karnym mają spacerniak, więc nie trzeba ich wypuszczać na
wolność, bo przecież mogą sobie tam pospacerować."

Gdybym ich zapytał, gdzie indziej by chcieli pójść, to każdy miałby 1000 pomysłów. A
jak Ciebie zapytałem co chciałbyś zrobić z kodem źródłowym Wolframa, to nie miałeś i
nadal nie masz odpowiedzi.

> A mówiąc konkretniej, te mechanizmy, które nie wymagają udostępniania kodu, nie
wymagają udostępniania kodu.

A które wymagają? Ciągle czekam na pomysł wykorzystania kodu. Wszystkie, które do tej
pory podałeś, nie wymagają.
Co może też świadczyć o tym, że Twoja potrzeba dostępu do kodu jest bardziej
psychologiczna, niż techniczna. W sensie - *wydaje* Ci się, że potrzebujesz tego
dostępu. I to jest OK, ale bądźmy racjonalni.

> > > Repozytorium ciekawe. Właśnie ściągam ponad 1gigową paczkę z "CDF playerem",
żeby móc odpalić. Niektóre dema działają w przeglądarce, a inne nie (te, które
działają, robią to "raczej tak sobie")
> >
> > Jakąś staroć wybrałeś. :-)
>
> Ale dlaczego to ma mieć znaczenie?

W sumie fakt. Natomiast warte zastanowienia jest to, czemu ten player na 1GB. Otóż
player musi umieć wykonać kod tego projektu, którzy ma odtworzyć - a może tam być
dowolna funkcja Wolfama. Czyli player to w rzeczywistości Mathematica, tylko z
ograniczonym UI.
Zainstaluj to raz, najlepiej normalną wersję.

> > [kod źródłowy]
> No nie wiem.
> Na przykład, jak chcę zobaczyć, jak działa odkurzacz, to biorę śrubokręt, rozkręcam
i patrzę sobie, jak działa odkurzacz.

Niestety zły przykład. Właściwie to się podkładasz w tej dyskusji.
Rozkręcanie odkurzacza śrubokrętem to jest zwykły reverse-engineering. Możesz to
zrobić z dowolnym programem, do tego znowu (!) nie jest potrzebny jego kod źródłowy.
Analogią kodu źródłowego w odkurzaczu są rysunki techniczne (czy jakieś wizualizacje
CAD, itd.). Czyli artefakty inżynierskie, tworzone na poziomie abstrakcji właściwym
dla dziedziny tego produktu. Czasem jest to rysunek mechaniczny, czasem technika
złożenia, czasem schemat elektryczny, czasem kod programu, itd.

I tych artefaktów inżynierskich *nie masz*. Producent je ma. Skąd więc obsesja na
punkcie kodu źródłowego, skoro nie masz rysunków technicznych odkurzacza?

BTW - współczesny odkurzacz to komputer z jakimiś nieistotnymi dodatkami typu pompka,
kółka, rurki jakieś, itp. A w tym komputerze jest kod, którego... nie masz. Czyli
naprawdę zły przykład.

> Zeszyty Mathematiki mają potencjał do tego, żeby stanowić medium komunikacji.

Tak. Mam to na uwadze.

> Naprawdę bym chciał, żeby tak było.

To zainstaluj.
BTW - na najnowszej wersji RaspberryPi (4) ma być Mathematika 12. I sądząc po
parametrach samego komputera, ten zestaw to już nie są żarty. Wolfram Cloud też
fajny, nawet na telefonie w tramwaju można się pobawić.

--
Maciej Sobczak * http://www.inspirel.com

do góry

Dnia Wed, 19 Jun 2019 15:12:14 -0700 (PDT), Maciej Sobczak napisał(a):

[...]
> Przykładowo, taką platformmą jest iOS (i zapewne Android).
> Jest konsola Pythona na to. Taki trochę dowód, że się da.
> Ale Wolfram App też na to jest. I co ciekawe, Wolfram App
> ma większy wpływ na upowszechnianie się tego produktu na
> desktopie (bo daje spójny wgląd do plików w chmurze - ale
> uwaga, to właśnie wymaga wsparcia ze strony dobrze działającej
> firmy komercyjnej), niż konsola Pythona, która na telefonie
> właściwie do niczego nie służy.
[...]

Czy stosuje się Wolframa'a do komunikacji
z systemami OBD w pojazdach samochodowych?

do góry

> Czy stosuje się Wolframa'a do komunikacji
> z systemami OBD w pojazdach samochodowych?

Zakładając, że OBD == "On-Board Diagnostics", to nie wiem, czy się stosuje. Nie widzę
specjalnie zalet takiego użycia. Ogólnie, pojazd samochodowy -> system wbudowany ->
być może jakiś real-time. W ogóle nie spodziewałbym się tam żadnego rozwiązania
opartego o systemy skryptowe czy maszyny wirtualne (Wolfram to maszyna wirtualna). Co
nie zmienia faktu, że twórcy takich rozwiązań nie mają oporów, żeby to robić.

Inna sprawa (spekuluję, bo nie rozwinąłeś pytania) to komunikacja z systemem
diagnostycznym gdy samochód jest w warsztacie. Wtedy nie mówimy o systemie wbudowanym
(ani o real-time), tylko o programie na zewnętrznym komputerze. Wtedy nie widzę
przeciwskazań, żeby użyć cokolwiek. Jeśli ktoś chciałby w ten sposób skorzystać z
Wolframowych zdolności do wizualizacji danych, to czemu nie. Albo z Wolframowej
chmury do masowej analizy danych. Albo z AI do predykcji napraw. To wszystko ma sens:

http://www.wolfram.com/system-modeler/examples/autom
otive-transportation/

http://www.wolfram.com/solutions/industry/control-sy
stems/

http://www.wolfram.com/solutions/industry/operations
-research/

--
Maciej Sobczak * http://www.inspirel.com

do góry

Dnia Fri, 28 Jun 2019 00:16:35 -0700 (PDT), Maciej Sobczak napisał(a):

>> Czy stosuje się Wolframa'a do komunikacji
>> z systemami OBD w pojazdach samochodowych?
>
> Zakładając, że OBD == "On-Board Diagnostics", to nie wiem, czy się stosuje. Nie
widzę specjalnie zalet takiego użycia. Ogólnie, pojazd samochodowy -> system
wbudowany -> być może jakiś real-time. W ogóle nie spodziewałbym się tam żadnego
rozwiązania opartego o systemy skryptowe czy maszyny wirtualne (Wolfram to maszyna
wirtualna). Co nie zmienia faktu, że twórcy takich rozwiązań nie mają oporów, żeby to
robić.
>
> Inna sprawa (spekuluję, bo nie rozwinąłeś pytania) to komunikacja z systemem
diagnostycznym gdy samochód jest w warsztacie. Wtedy nie mówimy o systemie wbudowanym
(ani o real-time), tylko o programie na zewnętrznym komputerze. Wtedy nie widzę
przeciwskazań, żeby użyć cokolwiek. Jeśli ktoś chciałby w ten sposób skorzystać z
Wolframowych zdolności do wizualizacji danych, to czemu nie. Albo z Wolframowej
chmury do masowej analizy danych. Albo z AI do predykcji napraw. To wszystko ma sens:
>
> http://www.wolfram.com/system-modeler/examples/autom
otive-transportation/
>
> http://www.wolfram.com/solutions/industry/control-sy
stems/
>
> http://www.wolfram.com/solutions/industry/operations
-research/


Pytanie było precyzyjne... i dobrze spekulujesz.
To mój drugi dzień z Wolframem.
Dziękuję za linki.

do góry

> To mój drugi dzień z Wolframem.

Czyli na tej grupie dyskusyjnej jest teraz więcej użytkowników Wolframa, niż np.
Clojure albo Haskella. :-D

> Dziękuję za linki.

Polecam się z pomocą. Myślę, że jakiekolwiek pytania/odpowiedzi na tej grupie mogą
pomóc również tym, którzy mają wątpliwości. Dlatego chętnie odpowiem na dalsze
pytania (w razie możliwości).

--
Maciej Sobczak * http://www.inspirel.com

do góry