Wiele razy czytałem w Internecie, że jeśli twój język nie obsługuje niektórych pojęć, na przykład orientacji obiektowej, a może wywołań funkcji, i jest uważany za dobrą praktykę w tym innym kontekście, powinieneś to zrobić.
Jedyny problem, jaki widzę teraz, to to, że inni programiści mogą uznać twój kod za inny niż zwykle, co utrudnia im programowanie. Jak myślisz, jakie inne problemy mogą z tego wyniknąć?
programming-languages
concepts
idioms
Julio Rodrigues
źródło
źródło
Odpowiedzi:
Jednym z problemów jest to, że możesz napisać dużo kodu, aby wyrazić coś w sposób, który zrobisz w innym języku, podczas gdy istnieje prostszy sposób w języku, którego używasz.
Na przykład w odpowiedzi na temat przepełnienia stosu wyjaśniłem, w jaki sposób kontrakty kodowe, koncepcja stosowana w .NET Framework, mogą być częściowo emulowane w PHP, który ich nie obsługuje. Skończyło się na tym, że napisałem dużo kodu za darmo, ponieważ to samo można zrobić z prostymi tablicami.
Mówiąc bardziej ogólnie, każdy język ma swoją kulturę, własne najlepsze praktyki, swój styl.
Gdybym zaczął pisać kod C # tak, jakby to był C, byłoby to brzydkie.
Jeśli pojmę Haskella jako programistę Java, który był zmuszony używać Haskella, ale nie chcę zrozumieć jego mocnych stron i po prostu chcę sklonować koncepcje Javy, kod, który napisałbym, ucierpi.
itp.
Nie ma nic złego w próbie ulepszenia języka (na przykład poprawienie C # poprzez wprowadzenie jednostek miary jak w F #), ale jeśli robisz to za dużo, powinieneś wybrać inny język, który faktycznie odpowiada twoim potrzebom.
źródło
Spadek czytelności sam w sobie jest wystarczającym problemem: drastycznie zmniejsza liczbę osób, które mogłyby potencjalnie utrzymać Twój projekt bez intensywnego szkolenia z twojej strony.
Dodatkowo,
źródło
To nie jest tak dobry pomysł, jak się wydaje na papierze.
Przykład 1: Jeśli jesteś wystarczająco stary, możesz pamiętać dni, kiedy C był nowym dzieckiem w mieście. Programiści Pascala i Ady nie lubili krótkich nawiasów klamrowych typu C. Zdefiniowali
beginiendotworzyli klamrę i zamknęli klamrę i voila! CAda! Niefortunny wynik był brzydki z punktu widzenia Ady lub C.Przykład 2, osobisty: Jedną z rzeczy, które bardzo mi się podobały w systemie Common Lisp Object System, są metody przed, po i wokół nich. Mogą być bardzo przydatne w wielu miejscach. Więc emulowałem tę koncepcję w C ++ w kilku wybranych miejscach. Jedynym sposobem na emulację tych konstrukcji w C ++ jest wymaganie od twórcy klasy pochodnej wywołania metody klasy nadrzędnej o tej samej nazwie we właściwym miejscu w kodzie. To wymagało od programistów, którzy wywodzili się z moich klas, co było nieco obce programowaniu w C ++, a być może wbrew ziarnom programowania w C ++. Bez względu na to, jak dobrze udokumentowano to wymaganie, ludzie po prostu nie przestrzegali wytycznych, ponieważ nie pasowało to do paradygmatu C ++.
źródło
Nieszczelne abstrakcje.
źródło
outparametrów w środowisku, które tak naprawdę ich nie obsługuje; C # zakłada, że każda funkcja zawsze zapisuje wszystkie swojeoutparametry, ale metody inne niż C # wywoływane metodami C # nie dają takiej gwarancji.To może być wyjątkowo trudne. Wyobraź sobie, że próbujesz zaimplementować LINQ z C # w swojej aplikacji Java. A może po prostu dodać leksykalne zamknięcia do języka? Będziesz musiał napisać nowy kompilator, który da ci zupełnie nowy język.
Lub, w przypadkach, w których nie musisz implementować własnego języka, wyobraź sobie, że próbujesz zaimplementować metody zbierania przy użyciu funkcji wyższego rzędu (takich jak map) w języku, który nie ma bloków kodu lub funkcji lambda, zamknięć lub funkcji jako pierwsze obiekty klasy. Każda funkcja wyższego rzędu musi być zadeklarowana jako interfejs i jawnie zaimplementowana, a wszystkie stany, które zostałyby uchwycone w zamknięciu, muszą być jawnie zapisane w klasie implementującej. Jest o tyle dodatkowe pisanie i o wiele trudniejsze do odczytania, że często nie jest tego warte.
źródło