Jak trudne byłoby udostępnić inne języki programowania?

Gdyby dozwolony był Rust, to obiecuję w nim kodować.

Dołączam się do pytania o możliwość dodania Rust'a...

Kiedyś było więcej:

https://web.archive.org/web/20170929201907/http://potyczki.mimuw.edu.pl:80/l/24/

"Dopuszczalne są jedynie programy w następujących językach programowania:
C
C++
Java (z wyjątkiem zadań rozproszonych)
Pascal (z wyjątkiem zadań rozproszonych)"

Przenośnym assemblerem można w jako tako pisać w c++, pascala nikt nie uzywał a na Javę ludzie narzekali bo wolna była ;-)

IMHO rust mogłby nam zwiększyć zasięgi (i nie ma, jak python, problemu z Java'y). Na pewnej grupie FB byłą nawet niedawno dyskusja o advent of code i dlaczego u nas jest badziwny odpowiednik, ludzie odpowiedzieli: przecież mamy PA:) Ale jednym z zastrzeżeń było waśnie ograniczenie języków do cepa.

Jak trudne by było. Jeśli dobrze rozumiem, skąd się bierze trudność, to dość upierdliwe. Te programy nie są uruchamiane bezpośrednio, tylko (chyba*) jakby emulowane. Ktoś to napisał dla c++. Dla innych (czy jakoś kombinować przez LLVM) - chętnych chyba nie ma. Jak są chętni, projekt to chyba SIO2.

*) Pewną przesłanką jest to, że kompilujemy wg standardu c++17, a uruchamiane ejst na "komputerach 32 bitowych" :)

Inne języki są problematyczne głównie przez zadania interaktywne, chcielibyśmy mieć możliwość zaskakiwania nimi i nieodcinania nagle kogoś piszącego w innym języku. To samo z zadaniami rozproszonymi, których powrotu nie wykluczamy.

W zadaniach interaktywnych można by rozwiązać ten problem poprzez komunikację przez stdio tak jak w nie-interaktywnych, zamiast linkowania ze sprawdzaczką.

Zalety:
* nie trzeba robić biblioteki w każdym języku
* interfejs taki sam jak w innych typach zadań
* limit pamięci nie jest dzielony ze sprawdzarką
* sama pamięć nie jest dzielona
* łatwiej przetestować rozwiązanie "ręcznie" z klawiatury

Potencjalna wada to że komunikacja międzyprocesowa jest wolniejsza niż wewnątrz-procesowa. Ale to chyba nie jest wielki problem, po prostu może musi być trochę większy limit czasu jeśli tej komunikacji jest bardzo dużo.

(powtarzam się, napisałem to samo w wątku "programowanie funkcyjne", ale piszę też tu dla zachowania kontekstu)

Ja Wam powiem jaka jest brutalna prawda co do innych języków programowania na PA. Może się trochę pomylę, ale na moje oko 95% osób startujących regularnie w konkursach używa C++, 4% Javy, a reszta Pythona czy jakichś innych wymysłów. W szczególności główni organizatorzy merytoryczni są "konkursowymi zawodowcami" i im używanie czegoś innego niż C++ do zadanek w ogóle nie przychodzi do głowy. Dlatego nie forsują jakoś szczególnie innych języków. Aczkolwiek tak naprawdę to nie od nich zależy, więc tak naprawdę ten wstęp jest mało relewantny. Wszystko zależy od technicznych, bo to oni zajmują się ogarnianiem funkcjonalności SIO. Na ile są oni leniami zbijającymi bąki, a na ile bardzo ciężko pracującymi ludźmi - nie mam pojęcia. Jednak jak ktoś miałby dodawać te więcej języków to oni, a co zrobić aby ich do tego zmotywować też nie wiem :). Potyczki rzeczywiście mają jakąś ciekawą własność popularyzatorską, dzięki której zgarniają ludzi z szerszego spektrum, dla których C++ nie jest głównym językiem, bo z competitive programming mają aktualnie wspólne PA raz na rok, a w pracy se tam programują w czymś innym i nawet jak widać tacy zawodowcy jak Tomek po jakimś czasie od zaprzestania regularnego uczestniczenia chętnie by zobaczyli więcej języków. Jednak właśnie to, że PA jest chyba jedynym znanym mi konkursem gdzie ludzie proszą o więcej języków sprawia, że ich dodawanie nie leży wśród priorytetów technicznych.

"Jednak jak ktoś miałby dodawać te więcej języków to oni" To nie za bardzo prawda. SIO2 jest open source, więc jeśli komuś będzie wystarczająco bardzo zależało to może samodzielnie spróbować dodać taką funkcjonalność. Na technicznych leżałoby tylko ewentualne wdrożenie tego do sio2 potyczkowego.