X++ co to za czort?

Jako że X++ wylądował w pierwszej 50 tiobe mam pytanie co to za czort? Na razie doczytałem że jest używany w Dynamics 365 od M$. A teraz próbuje zrozumieć co to Dynamics 365 i czemu nie użyli tam jednezo z już swoich istniejących języków jak C#/F# czy któryś Basic

Słyszał ktoś coś o tym?

Pozdrawiam

Pierwsze słyszę :o

@KamilAdam: cytując wiki

X++ - język programowania wykorzystywany w rodzinie systemów ERP II Microsoft Dynamics AX Axapta. Oparty składniowo na C#, poszerzony między innymi o obiektową obsługę baz danych, raportów i formularzy oraz komendy SQL.

Poza tym tu masz oficjalne info https://learn.microsoft.com/en-us/dynamicsax-2012/developer/x-language-programming-guide

W dyżym uproszczeniu jak vba dla office, to x++ jest dla produktów dynamics

Są różne języki dla produktów Dynamics, wymienię 3 podstawowe:

• Dynamics 365 Finance & Operations: X++
• Dynamics 365 Business Central: AL
• Dynamics 365 Customer Engagement: .NET.

Microsoft wykupił dwa pierwsze produkty od innej firmy, przez co język programowania już był tam zaimplementowany. Aczkolwiek MS rozwija te systemy i środowisko programistyczne jest całkiem przyjemne.

Pewnie to trzymają, żeby "nie defekować" w samego C# i .Neta a taki X++ przyjmie wszystko i pewnie jeszcze może się zmieniać s kolejnymi wersjami oprogramowania bez wstecznej kompatybilności.

Ciekawe. Nie no dużych podobieństw do C# nie widzę, to jakaś dziwna hybryda C# z C++ i elementów nie wiem czego... pascala? Na pierwszy rzut oka to takie C++/CLI pisane na kolanie, jakby na siłę próbowali zrobić język którego nie będzie się miło używało. Przeglądając szybko dokumentację:

All declarations must be at the start of the method, before any X++ statements.

Dlaczego?!

In C# you can declare the counter integer in the for statement. But in X++ the counter must declared outside the for statement.

?? czemu

In X++ the modulo operator is mod.

:|

There is no char or character type in X++. You can declare a str of length one, but it is still a string: str 1 myString = "a";

...

The if statement accepts any type of expression that it can automatically convert to a Boolean. Common examples include an int for which 0 means false, or an object for which null means false.

czyli jak w c, powrót do yoda notation

An ++ increment operator is available in X++. But an int variable that is decorated with ++ can only be used as a statement, not as an expression. For example, the following lines of X++ code would not compile: int age=42; print age++;

The == and != operators are case insensitive in X++
"HELLO" == "hello"
True in X++.

wtf

Delete the Second Item
literator.begin();
literator.next();
literator.delete();

Błagam żebym nigdy nie musiał dotykać tego języka.

obscurity napisał(a):

Ciekawe. Nie no dużych podobieństw do C# nie widzę, to jakaś dziwna hybryda C# z C++ i elementów nie wiem czego... pascala? Na pierwszy rzut oka to takie C++/CLI pisane na kolanie, jakby na siłę próbowali zrobić język którego nie będzie się miło używało. Przeglądając szybko dokumentację:

All declarations must be at the start of the method, before any X++ statements.

Dlaczego?!

In C# you can declare the counter integer in the for statement. But in X++ the counter must declared outside the for statement.

?? czemu

In X++ the modulo operator is mod.

:|

There is no char or character type in X++. You can declare a str of length one, but it is still a string: str 1 myString = "a";

...

The if statement accepts any type of expression that it can automatically convert to a Boolean. Common examples include an int for which 0 means false, or an object for which null means false.

czyli jak w c, powrót do yoda notation

An ++ increment operator is available in X++. But an int variable that is decorated with ++ can only be used as a statement, not as an expression. For example, the following lines of X++ code would not compile: int age=42; print age++;

The == and != operators are case insensitive in X++
"HELLO" == "hello"
True in X++.

wtf

• to że deklaracje mają być na górze, to faktycznie słabe.
• to że modulo jest pisane mod to też nic dziwnego. Python ma jakoś not zamiast !, nie widzę czemu nie mogłoby być mod zamiast %.
• to że nie ma char to też moim zdaniem jest normalne. Albo użyć stringa albo zrób byte. Nie wiem po co Ci dwa typy danych osobno na byte i osobno na char.
• to że if robi implicit casta do bool, to nie jest nic nowego, sporo języków tak robi, nie tylko C++
• to że ++ to jest statement, i nie można go zwracać, to moim zdaniem jest dobre, bo przynajmniej CQS, czyli albo zmieniasz albo czytasz. Moim zdaniem to jest spoko.
• To że == jest case insensitive to faktycznie jest fuckup.
• To że jest iterator z .begin(), .next(), i .delete() to jest normalne. Byłoby nie normalne gdyby to był jedyny sposób usunięcia drugiego elementu. Poza tym, to tylko biblioteka standardowa. Banalnie byłoby to wydzielić, także moim zdaniem to jest normalne.

Riddle napisał(a):

• to że nie ma char to też moim zdaniem jest normalne. Albo użyć stringa albo zrób byte. Nie wiem po co Ci dwa typy danych osobno na byte i osobno na char.

Nie każdy znak mieści się w bajcie, bo znaków jest już trochę więcej niz 256 XD

KamilAdam napisał(a):

Riddle napisał(a):

• to że nie ma char to też moim zdaniem jest normalne. Albo użyć stringa albo zrób byte. Nie wiem po co Ci dwa typy danych osobno na byte i osobno na char.

Nie każdy znak mieści się w bajcie, bo znaków jest już trochę więcej niz 256 XD

Racja.

No ale nawet, jeśli to ma być unicode lub kilka bajtów w innym kodowaniu, to czemu do tego nie użyć String po prostu?

Riddle napisał(a):

KamilAdam napisał(a):

Riddle napisał(a):

• to że nie ma char to też moim zdaniem jest normalne. Albo użyć stringa albo zrób byte. Nie wiem po co Ci dwa typy danych osobno na byte i osobno na char.

Nie każdy znak mieści się w bajcie, bo znaków jest już trochę więcej niz 256 XD

Racja.

No ale nawet, jeśli to ma być unicode lub kilka bajtów w innym kodowaniu, to czemu do tego nie użyć String po prostu?

W dynamicznych jak JS czy Python to wszystko jedno. Ale w statycznie typowanych językach jest zwykle osobny typ Char żeby nie było sytuacja że ktoś wywoła nextChar "Ala ma kota" i dostanie RuntimeException. Oczywiście czasem ten typ char jest zdupczony, bo w C załozyli że znaków jest tylko 256, a w Javie że jest 256*256 XD W rezultacie char w Javie jest nieużywalny i mamy takie kwiatki jak

IntStream intStream = testString.chars();

i zamiast charów są używane inty XD

Riddle napisał(a):

No ale nawet, jeśli to ma być unicode lub kilka bajtów w innym kodowaniu, to czemu do tego nie użyć String po prostu?

Żeby sprawdzać błędy na poziomie typów a nie w kodzie za pomocą ifów. W pythonie wywołanie ord("sd") zwraca TypeError: ord() expected a character, but string of length 2 found.

Z drugiej strony przyjęcie strategii, że char to len(string) == 1 sprawia, że sam język jest prostszy kosztem konieczności wprowadzenia checków w kilku niewygodnych miejscach jak wspomniane już ord

KamilAdam napisał(a):

W dynamicznych jak JS czy Python to wszystko jedno. Ale w statycznie typowanych językach jest zwykle osobny typ Char żeby nie było sytuacja że ktoś wywoła nextChar "Ala ma kota" i dostanie RuntimeException.

Tak czy tak musisz tego chara jakoś dostać; jak bierzesz go ze stringa to tak czy tak możesz dostać RuntimeException.

No okej, trochę lepszy system typów, jeśli masz typ pod znak. Tylko żę nawet brak takiego typu w bibliotece standardowej niewiele zmienia, bo nawet jak nie ma czegoś takiego, to banalnie można go zrobić,

class Char {
  String char;
  Char(String string) {
    this.char = string;
    if (string.length !== 1) throw InvalidChar();
  }
  toString() {
    return char;
  }
}

i wszędzie gdzie byś chciał użyć wbudowanego typu char, możesz użyć swojego typu Char.

Tak czy tak, tak jak przyznaje @obscurity że daklaracje dozwolone tylko na górze metody to niezły paskalowy fuckup, to że == jest case-sensitive również jest słabe; tak pozostałe "wrzuty" jak np brak tego typu char, to dla mnie jest zwykła normalka.

slsy napisał(a):

Riddle napisał(a):

No ale nawet, jeśli to ma być unicode lub kilka bajtów w innym kodowaniu, to czemu do tego nie użyć String po prostu?

Żeby sprawdzać błędy na poziomie typów a nie w kodzie za pomocą ifów. W pythonie wywołanie ord("sd") zwraca TypeError: ord() expected a character, but string of length 2 found.

Z drugiej strony przyjęcie strategii, że char to len(string) == 1 sprawia, że sam język jest prostszy kosztem konieczności wprowadzenia checków w kilku niewygodnych miejscach jak wspomniane już ord

No tak; tylko weź pod uwagę że takie błędy są stosunkowo rzadkie, gdzie faktycznie masz funkcje która przyjmuje jeden i tylko jeden znak; a dodatkowy wbudowany typ jest stosunkowo znaczną komplikacją języka. Weź duży projekt, w standardowej aplikacji - jaka może być objętność kodu która faktycznie polega na tym ze jakaś zmienna ma jeden znak, bardzo mała. char to nie jest int czy bool, który przesiąka aplikację do szpiku, tylko jest używany gdzieniegdzie. Plus tak czy tak musisz pod te elementy mieć testy które to wykryją, wtedy to czy to jest wbudowany char czy nie to jest szczegół implementacyjny. A complexity języka przez ten jeden wbudowany typ idzie w górę.

Riddle napisał(a):

KamilAdam napisał(a):

W dynamicznych jak JS czy Python to wszystko jedno. Ale w statycznie typowanych językach jest zwykle osobny typ Char żeby nie było sytuacja że ktoś wywoła nextChar "Ala ma kota" i dostanie RuntimeException.

Tak czy tak musisz tego chara jakoś dostać; jak bierzesz go ze stringa to tak czy tak możesz dostać RuntimeException.

Wut? Niby dlaczego miałbym dostać RuntimeException? jak wyjdę poza zakres odwołujac się do nie istniejącego elementu to tak, ale np iteruję po elementach stringa to czemu miałbym RuntimeException ?

No okej, trochę lepszy system typów, jeśli masz typ pod znak

I tu mógłbyś skończyć

Tylko żę nawet brak takiego typu w bibliotece standardowej niewiele zmienia, bo nawet jak nie ma czegoś takiego, to banalnie można go zrobić,

Ale wolisz brzmieć jak programista Asma/C -> " Brak klas i obiektów w C w ogóle mi nie przeszkadza bo w bardzo prosty sposób moge je sobie dopisać sam" :P

Riddle napisał(a):

Plus tak czy tak musisz pod te elementy mieć testy które to wykryją, wtedy to czy to jest wbudowany char czy nie to jest szczegół implementacyjny. A complexity języka przez ten jeden wbudowany typ idzie w górę.

Dla mnie to podobna dyskusja co static vs dynamic. Mając osobny typ nie musimy pisać testów do wielu przypadków: nie mogę przepchać stringa, który nie jest charem, bo nie pozwala na to dziedzina funkcji. W przypadku języków statycznych ma to sens, w przypadku dynamicznych i tak jest możliwość przepchania wszystkiego więc takie złączenie typów ma sens.

slsy napisał(a):

Riddle napisał(a):

Plus tak czy tak musisz pod te elementy mieć testy które to wykryją, wtedy to czy to jest wbudowany char czy nie to jest szczegół implementacyjny. A complexity języka przez ten jeden wbudowany typ idzie w górę.

Dla mnie to podobna dyskusja co static vs dynamic. Mając osobny typ nie musimy pisać testów do wielu przypadków: nie mogę przepchać stringa, który nie jest charem, bo nie pozwala na to dziedzina funkcji.

Tylko że takie testy są słabe, bo są zbyt przwiązane do implementacji. Powinieneś napisać testy o szerszym scope'ie, i wtedy ten typ jest szczegółem implementacyjnym (test nie wiem czy używasz wbudowanego chara czy swojego), i tak czy tak musisz napisać testy pod to.

S4t napisał(a):

Pewnie to trzymają, żeby "nie defekować" w samego C# i .Neta a taki X++ przyjmie wszystko

Przecież C# już przyjmuje wszystko. :|

KamilAdam napisał(a):

Jako że X++ wylądował w pierwszej 50 tiobe mam pytanie co to za czort? Na razie doczytałem że jest używany w Dynamics 365 od M$. A teraz próbuje zrozumieć co to Dynamics 365 i czemu nie użyli tam jednezo z już swoich istniejących języków jak C#/F# czy któryś Basic

C#, F# i VB.NET się nie nadają. Zwłaszcza C#.
Trzeba by te języki okroić. A jak już kroimy, to i tak wyjdzie inny język. Będzie go używało mało ludzi, więc można go zaprojektować tak, aby łatwiej było twórcom języka niż twórcom aplikacji (ten X++ właśnie tak wygląda).

Trochę to wygląda jak Dexterity, a to coś takiego jak ABAP dla SAP.
No jak trzeba to się w tym rzeźbi.
Ale tylko jak nie ma innego wyjścia ;-)

somekind napisał(a):

aby łatwiej było twórcom języka niż twórcom aplikacji (ten X++ właśnie tak wygląda).

super :)

Microsoft Axapta - fajne ERP pisałem w tym kilka lat. Specyficzna filozofia pisania. Każdy obiekt ma swój fragment kodu. Nie ma czegoś takiego jak "pliki z kodem źródłowym".
Porąbane jak diabli ale ma to sens. Bardzo ogólne i wychodzą z wysokiego poziomu abstrakcji - daje to sporo ograniczeń ale i możliwości np. mogłeś oznaczyć / przełączać czy ten sam kod wykonujesz po stronie klienta czy serwera. Ciekawa rzecz polecam zapoznać się tym co szukają nowych wyzwań. Mi dużo dało spotkanie z tym środowiskiem i w sumie ciągle korzystam i wdrażam w nowych systemach z pomysły i rozwiązania, które tam stosowano.