Czy są dostępne języki na najwyższym poziomie? [Zamknięte]

Historycznie HLL to coś w rodzaju C, Fortran lub Pascal, a VHLL to coś w rodzaju Ruby lub Python. Znam pojęcia 4GL, 5GL, DSL i LOP, a ci, którzy nie są, powinni przeczytać definicje w Wikipedii. Szukam UHLL.

Moje pytanie brzmi: czy są dostępne języki komputerowe, które są bardziej wydajne o jeden rząd wielkości i czy ktoś nad nimi pracuje?

Bardziej produktywny oznacza mniej autorskiego kodu i mniej czasu programisty na osiągnięcie wyniku, mniej błędów i mniej debugowania, bliższe koncepcyjne powiązanie kodu z wymaganiami, mniej wysiłku na modyfikację i utrzymanie.

Główną domeną, która mnie interesuje, są aplikacje biznesowe i konsumenckie ogólnego zastosowania, z graficznym interfejsem użytkownika lub interfejsem przeglądarki, trwałością danych i połączeniami z innymi systemami, takimi jak drukowanie i poczta elektroniczna. Inni ludzie mogą skupić się gdzie indziej.

Rozumiem, że niektóre z tych języków mogą być specyficzne dla domeny i że mogą one być czymś więcej niż możliwościami konfiguracji dużej i sprawnej aplikacji. Arkusze kalkulacyjne Excel należą do tej kategorii.

Rozumiem, że niektóre z tych języków mogą wydawać się ogólne, ale nadal mogą mieć wąski zakres i nieprzystosowane do wielu problemów. Na przykład Matlab może nie być dobrym wyborem dla programu zajmującego się głównie interakcją użytkownika i danymi tekstowymi.

Znam niektóre funkcje, które mogą znajdować się w UHLL, analogicznie do VHLL. Spodziewałbym się znaleźć jeden lub więcej z poniższych (i dodaj do listy):

• Rysunek formularza GUI JEST programem dla formularza GUI
• Tabela zawierająca wiersze, kolumny i nagłówki JEST programem dla tabeli w bazie danych
• Logika deklaratywna mówi, co należy zrobić i kiedy, bez instrukcji IF
• Operacje na zestawach danych, bez pętli FOR
• Wykonanie niesekwencyjne, np. Sterowane danymi, dopasowywanie wzorów, chodzenie po drzewie

Motywem tego pytania jest to, że coraz bardziej mam dość ciężkiej pracy polegającej na tłumaczeniu stosunkowo prostych wymagań biznesowych na duże ilości kodu, aby zaspokoić potrzeby komputera. Pytanie naprawdę dotyczy znalezienia innych osób, które podzielają mój ból i pracują nad podniesieniem poziomu języków i sprawieniem, aby komputer wykonał więcej ciężkiej pracy. To był główny cel w latach 70. i 80., ale czy nadal tak się dzieje?

Oto niektóre sugerowane odpowiedzi na moje pytanie, podane tutaj w celu streszczenia lub wyliczenia języków, które znam, i które moim zdaniem nie są wystarczające.

Istnieje wiele języków, które są HLL lub VHLL i zawierają indywidualne funkcje należące do wyższego poziomu. Użyłem większości z nich (często źle). Zawierają

• Lisp, z makrami i możliwością samodzielnej modyfikacji
• Haskell, z zależnością danych i dopasowaniem wzorca
• SQL, który zajmuje się wierszami i tabelami
• Rebol, co wydaje się sprytne, ale tak naprawdę tego nie rozumiem
• APL (i J) z wielowymiarowymi tablicami i ultrakompaktowymi operatorami
• C # z LINQ
• AWK / Perl / Python / Ruby z wbudowanymi wspaniałymi kolekcjami i wyrażeniami regularnymi

Te języki mają zbyt wiele funkcji niskiego poziomu, aby mogły być używane w języku UHLL. Programista musi jeszcze napisać wiele konstrukcji niskiego poziomu dla każdego przydatnego programu.

Istnieją pakiety RAD / 4GL. Użyłem trochę:

• dBase / Foxpro
• Dataflex / Powerflex (mój produkt)
• Dostęp
• PowerBuilder

I wiele innych nie korzystałem. Najczęściej językiem jest w najlepszym przypadku HLL, ale pakiet zawiera strukturę i uprzywilejowane połączenia między językiem a pakietem, dzięki czemu aplikacje można szybko budować. Nie jestem pewien, dlaczego to podejście zabrakło pary, ale w każdym razie UHLL tak nie jest.

Istnieją surowe frameworki / biblioteki. Użyłem kilku:

• Szyny
• Java awt i swing
• .NET Windows Forms, WPF i ASP.NET.

Są to obecnie najnowocześniejsze rozwiązania. Pozostawiają programistę mocno uwięzionego w błocie języka implementacji, radząc sobie ze złożonością na każdym kroku. To nie jest UHLL, ale możliwe jest zbudowanie UHLL na jednym z nich.

Istnieją narzędzia do projektowania, takie jak UML i zestaw narzędzi Rational, których nie znam dobrze. O ile widzę, pomagają one sformułować wymagania biznesowe, ale nigdy nie mogą zastąpić etapu programowania. Nie chcę eliminować programistów, po prostu wykonuj więcej na jednostkę czasu i wysiłku.

Myślę, że po wyeliminowaniu wszystkich kandydatów mam nadzieję, że ktoś inny może zapewnić lepszego kandydata.

Późna edycja: Myślę, że mam odpowiedź: język Wolfram. http://www.wolfram.com/wolfram-language/

Prawie wszystkie kryteria Państwo liście są rzeczy już wypróbowane w narzędzia 4GL / RAD takich jak MS Access, Sybase Elektrowni Builder, Oracle Forms, Ruby-on-Rails (jako bardziej nowoczesne próbki dla Web Apps), i wiele innych (patrz Wikipedia dla bardzo długa lista dostawców). I rzeczywiście, dzięki tym narzędziom można bardzo szybko przełożyć stosunkowo proste wymagania biznesowe na jakiś program. Dlatego większość dostawców narzędzi RAD reklamuje swoje produkty w taki sposób, że wszyscy powinni myśleć, że już wymyślili UHLL w twoim znaczeniu.

Haczyk polega na tym, że gdy tylko opuścisz wymagania, które są „ względnie proste ”, i gdy tylko będziesz musiał utrzymywać i rozwijać programy napisane w tych środowiskach, zauważysz, że łatwo osiągasz granice i dostrzegasz ich wady. , lub że wdrożenie z nimi wymagań nie jest w żaden sposób prostsze niż z jakimkolwiek innym „VHLL”, o którym myślisz. IMHO ma duże szanse, że zabiją wszelkie ulepszenia wydajności, które miałeś w wersji 1.0, gdy przejdziesz dalej do wersji 1.1, 1.2 i 1.3 twojego programu.

Jeśli chcesz zbudować oprogramowanie spełniające złożone wymagania, potrzebujesz złożonego środowiska programistycznego. Nadal nie ma srebrnej kuli , przez lata tylko stopniowo poprawialiśmy wydajność, a nie „rząd wielkości” wydajności w jakimkolwiek obecnym języku programowania w stosunku do swoich poprzedników (przynajmniej przez ostatnie 30 lat, co jest w przybliżeniu czasem przeszłość, kiedy opublikowano artykuł Brook'a).

Językiem programowania najwyższego poziomu, który znam, jest APL . Wymaga specjalnej klawiatury do przedstawienia wszystkich niezbędnych symboli. Obejrzyj ten film , w którym autor pisze pełną implementację Gry życia Conwaya w około siedem minut.

Prawdziwe pytanie oczywiście brzmi „czy to jest praktyczne?” Czy mogę znaleźć na świecie wystarczającą liczbę programistów APL, aby utrzymać działalność w ten sposób? Czy APL będzie działał na telefonach i tabletach? Czy naprawdę muszę kupować nowe klawiatury wszystkich programistów?

Jeśli naprawdę chcesz zwiększyć wydajność, najlepszym wyborem jest prawdopodobnie wariant Lisp. Clojure działa na JVM i ma port .NET. Mówię to, ponieważ ludzie już to zrobili; wyszukiwarka Orbitz działa na Lisp, a Paul Graham prowadził całą firmę za pomocą Lisp, twierdząc, że dało mu to znaczącą przewagę nad konkurentami (wszyscy korzystający z Javy).

Zauważ, że im wyższy poziom języka programowania, tym bardziej jest on usuwany z rzeczywistego sprzętu i tym bardziej prawdopodobne jest, że będziesz mieć problemy z wydajnością. O ile nie masz naprawdę wyrafinowanych kompilatorów, możesz od czasu do czasu kodować krytyczne pod względem wydajności części aplikacji w bardziej wydajnych językach niższego poziomu.

I wciąż jest kwestia posiadania krytycznej masy programistów zorientowanych w języku. Pomimo wszystkich brodawek nigdy nie będziesz mieć problemu ze znalezieniem programisty Java.

Pamiętaj, że języki głównego nurtu wciąż się rozwijają. Linq został stworzony w tym celu, aby uczynić programowanie oparte na danych bardziej deklaratywnym. Kilka nowych funkcji zostało dodanych do języka C #, aby Linq działał; wszystkie mają związek z poprawą wydajności programistów.

Dalsza lektura
Pokonywanie średnich

Wydaje mi się, że wskazałeś trochę na punkcie podziału, który ogranicza istnienie języków Ultra High Level - w pewnym momencie nie identyfikujemy ich już jako języków programowania.

Najlepszym przykładem tego specyficznego zjawiska, o którym jestem świadomy i który może być potencjalnie bardzo interesujący, jest Unified Modeling Language . Rzeczywiście istnieją specjalne stosy aplikacji, które zostały opracowane specjalnie do tego, o co prosisz. Spełnia wiele twoich wymagań, ale niekoniecznie tak, jak myślisz. Jest to jednak niezwykle pouczające w tej sytuacji, ponieważ podobnie się czułem, a moje doświadczenie (które następuje) zmieniło sposób myślenia o tym problemie.

Będę tu osobiście mówić o IBM Rational Software Architect , który jest próbą naprawdę umożliwienia rozwoju Ultra High Level. Celem jest, abyś mógł stworzyć filozoficzną koncepcję biznesową jako obiekt, taki jak Aktor lub Klasa, nadać atrybutom bytu, zdefiniować połączenia, zdefiniować sposób przepływu informacji przez system podczas pracy i zrobić to wszystko z GUI.

Możesz na przykład przeciągnąć obiekt DataStore, aktora, formularz, kilka odpowiednich klas (takich jak Klient itp.), Narysować linie połączeń między obiektami za pomocą grafów itp. I boom: po zakończeniu publikujesz działający program. (jest to oczywiście bardzo uproszczone)

Rzeczywiście, zostało zrobione tworzenie złożonego GUI, bardzo dokładna implementacja / interpretacja UML, a następnie kompilacja do kodu Java / C # / VB z pełnymi dokumentami XML zawierającymi informacje o grafice UML, a także implementują / włączają Round-Trip Engineering, dzięki czemu możesz przechodzić między modelami i kodami, aby kontrolować rzeczy zarówno na bardzo wysokim poziomie filozoficznym, jak i na bardzo niskim poziomie, specyficznym dla platformy.

To wszystko, czego chcesz i więcej, a nic nie rezygnujesz z wymiany! Dobrze?

Dlaczego nie wszyscy go używają?!?!

... no cóż, o to chodzi. To, co tak naprawdę kończy się, to monolityczne przedsięwzięcie, wszystko wymaga dużo ruchomych części i magii, wszystko jest - lub czasami nie - skutkiem zmiany w dowolnym z wielu różnych miejsc (w GUI, XML, niższy poziom kod, modele UML, które same są tworzone / definiowane / utrzymywane na wielu różnych poziomach modelu).

Gra jest naprawdę fajna, ale jest ... jak to powiedzieć ... ma bardzo wysoką krzywą uczenia się, została zaprojektowana z myślą o wielu dyscyplinach i naprawdę musisz traktować to jako zupełnie nową rzecz, która umożliwia niewielką - bardzo małą - uogólnienie na inne umiejętności, które już posiadasz.

Najważniejsze jest to - nawet wtedy, gdy miliony na miliony zostały wlane do projektu z kilkudziesięciu firm i kilka bardzo dużych nazwisk za nim, nadal kończysz się kodem w stylu C na warstwie wykonywalnej, która musi być czasami edytowana bezpośrednio , ponieważ niektóre rzeczy po prostu nie powodują tłumaczenia między opisami klas zorientowanych obiektowo a UML na poziom programowania / maszyny, a automatyzacja po prostu nie może być do końca zakończona.

Z mojego doświadczenia wynika, że ​​był to niezwykle skomplikowany sposób generowania rusztowań. To prawdopodobnie najokrutniejsza rzecz, jaką kiedykolwiek powiem o tak ogromnym przedsięwzięciu technologicznym, ale to właśnie z tego czerpię.

Od ludzi z branży, z którymi rozmawiałem, niestety powiedzieli to samo. Mieli wrażenie, że wykonali dużo pracy, tworząc dokumentację, niezliczone diagramy, modele, spotkania, analizy, przez miesiące i miesiące, a następnie wyrzucili to wszystko, a zespół programistów po prostu napisał kod i często traktował go jako Jeszcze Kolejny segregator specyfikacji (którego nikt nigdy nie czyta). Teraz używają tylko Javy i specjalnego oprogramowania do tworzenia diagramów / wizualizacji oraz Agile, i to już koniec tej historii.

Może to niesprawiedliwe i działa, gdy robisz to dobrze. Być może, ale od konsultantów i profesorów, z którymi rozmawiałem, twierdzili, że spędzili wiele godzin na specjalnych wielotygodniowych warsztatach programistycznych, pracując nad nauką systemu, wracając do dalszych szkoleń i dosłownie spędzając lata, aby nauczyć się, jak to zrobić praca i co idzie gdzie.

Ale może to wszystko wina programistów, że po prostu odmawiają przyjęcia systemu, który działa tak dobrze, a jednak wcale nie przypomina programowania komputerowego. Być może programiści korzystający z czystego kodu po prostu nie chcą zastąpić swoich zadań, tak jak dawni producenci świec i tkacze, i dlatego odmawiają wykonania ograniczonego zadania implementacji do specyfikacji, co powoduje, że wszyscy są tak sfrustrowani, że wyrzucają to i mówią złe rzeczy, i to było prawie idealne.

Ale ... Myślę, że może być w tym trochę prawdy, ale myślę, że przeważnie nie działa tak dobrze. Myślę, że to zmienia coś, co nie jest tak trudne przez większość czasu (programowanie komputerowe), i czyni to jeszcze trudniejszym do tego stopnia, że ​​gdyby to zadziałało, byłoby świetnie, ale cholera, masz długi czas bez niczego do pokaż, żeby się tam dostać!

Może zadziałałoby to tylko w przedsiębiorstwie z ponad tysiącem zespołów ludzkich, a może jeszcze nas tam nie ma.

Nie wiem.

Jednak studium tego, co jest dobre, a co złe, przy takim podejściu do języków Ultra High Level - i myślę, że należy wziąć pod uwagę rodzaj UML - naprawdę musi brać pod uwagę takie rzeczy, jak Rational Software Architect, aby uniknąć potencjalni głupcy.

A może po prostu musimy poświęcić kolejne 20-50 lat ciężkiej pracy. Nie jestem już optymistą, że język programowania jest już ograniczeniem.

A jeśli języki programowania były wcześniej ograniczeniem, to dlatego ulepszenia dały nam potencjalną poprawę wielkości. Jeśli nie są już one takim ograniczeniem, to o wiele bardziej prawdopodobne jest, że każda innowacja nie będzie w stanie zapewnić takiej kolejności poprawy. Ale nie mogę powiedzieć przyszłości! Zakładam więc, że reszta nie jest „w pracach”, ale na pewno „za wcześnie, aby powiedzieć”.

Jeśli pomyślisz o tym przez chwilę, programowanie wyższego poziomu jest w zasadzie w stanie skomponować mniejsze części, które są łatwo dostępne i sprawdzone. Aż do momentu, gdy twój program jest bardzo prostym kodem kleju różnych bibliotek. Może klej to bardzo wyrazisty DSL. Możesz to zrobić w każdym języku programowania.

Osobiście coraz bardziej zaczynam wyczuwać, że rozwiązanie kompozycyjności jest - w przeciwieństwie do tego, co możesz instynktownie odczuć - nie znajduje się w programowaniu obiektowym. Ten paradygmat, podobnie jak programowanie imperatywne, zapewnia programistom zbyt dużą swobodę, co z kolei utrudnia pisanie kodu, który można łatwo użyć ponownie.

Uważam raczej, że programowanie funkcjonalne dostarcza prymitywów, które są znacznie lepiej dostosowane do kompozycji. Czyste funkcjonalne języki programowania również nie pozwalają definiować funkcji, które mają skutki uboczne, co nie tylko zmniejsza błędy lub ułatwia ich wykrywanie, ale także ułatwia ich rozbudowę (skomponowanie ich do większego systemu).

Jeśli interesuje Cię programowanie funkcjonalne, możesz spojrzeć na nowoczesne języki funkcjonalne, takie jak Haskell . Myślę, że moduł Parsec zapewnia ładny, wysoki poziom DSL (zwany biblioteką kombinatoryczną w żargonie funkcjonalnym) do analizy. Istnieją również funkcjonalne reaktywne ramy programistyczne dla Haskell, które pozwalają budować potężne GUI z kilkoma liniami kodu.

Spodziewałbym się, że Lua, używana przez grę do pisania swoich zadań i interfejsów, spełni te kryteria. Istnieją również podobne języki specyficzne dla domeny (i narzędzia do tworzenia map), dzięki którym projektanci poziomów mogą szybko i łatwo powiedzieć „kiedy gracz rozmawia z Bobem, rozpocznij epicką przygodę Boba”.

Znam kilka innych ezoterycznych języków, które koncentrują się na przenoszeniu kodu do opisywania tego, co się dzieje, a nie tego , jak należy to zrobić. Niektórzy koncentrują się na bardzo deklaratywnym, logicznym podejściu. Niektórzy koncentrują się na programowaniu reaktywnym. Niektórzy koncentrują się na tym, aby to zrobić (szczególnie w przypadku rzeczy, które muszą być możliwe do zrównoleglenia). Niektórzy koncentrują się na prostym uczynieniu składni bardziej naturalną - przy założeniu, że naturalna składnia prowadzi do mniejszej liczby błędów spowodowanych tłumaczeniem między językiem naturalnym a kodem.

Żadne z nich nie jest tak obiecujące, jeśli chodzi o produktywność o rząd wielkości wyższą produktywność dla twórców rang i plików.

Myślę, że REBOL może spełniać wszystkie twoje kryteria. Możesz tworzyć stosunkowo wyrafinowane aplikacje GUI w kilku liniach kodu - jednak jego „specjalnością” jest tworzenie DSL.