Mutable a immutable oraz funkcyjność

Ciężko mi załapać wyczucie, kiedy tworzyć nowy obiekt a kiedy modyfikować istniejący. Chodzi mi o kolekcje: mam np. zbiór wierzchołków grafu, które będę odczytywał z pliku, da się je dodawać i usuwać. Raczej mutable, prawda?
I dalej. Mam zbiór zaznaczanych (nie zaznaczonych, bo klawisz myszy nie został zwolniony) w danym momencie punktów. Korci żeby użyć zbioru immutable, no bo w końcu gdzieś trzeba.
Trzecia sprawa. Przechowywanie zaznaczonych punktów. Mam w klasie wierzchołka pole selected. Zastanawiam się czy korzystać zamiast/dodatkowo ze zbioru zaznaczonych wierzchołków. Mianowicie: gdy chcę dostać zaznaczone wierzchołki, to mogę użyć filter(v=>v.selected). Jeśli np oprócz tego stworze zbiór, to jeśli on nie będzie zmienialny, to ciągle będę przypisywać do obiektu selVerts nową kolekcję.
Cały post w jednym zdaniu: gdzie używać tych niezmiennych kolekcji?!

Jeśli ktoś ma jeszcze czas na małą dywagację:
scala jest bardzo obiekto-żerna. Funkcja dająca się wysłać do innej funkcji to nic innego jak obiekt z metodą typu apply. Dodatkowo te niezmienne kolekcje. Logiczne z matematycznego punktu widzenia, bo Set(1,2,3) po dodaniu elementu 4 jest już innym zbiorem. Ale czy to jest na komputery, z których korzystamy, czy na szybsze komputery przyszłości? Bo np funkcyjność można fajnie wykorzystać, gdyby jednocześnie wykonywać więcej obliczeń: aby uzyskać kolekcję elementów o jeden większych, dla każdego elementu można by odpalić coś w rodzaju procesu, zamiast imperatywnie przechodzić po liście i robić to po kolei. Ale mam wrażenie że w tej chwili funkcyjność to dodatkowa warstwa abstrakcji która tylko ułatwia życie programiście a utrudnia komputerowi.

Naprosciej -> staraj sie uzywac immutable, potem lecisz profilerem i sprawdzasz gdzie to byl poroniony pomysl.
Ciut trudniej -> trzeba miec ciut wyczucia i wiedziec co z tym dokladnie robisz, ile razy i w jakim czasie. Jesli zobaczysz, ze cos ma za duzo modyfikacji to po prostu uzywasz jakiegos buildera/mutable kolekcji.

Emulowanie mutowalnych kolekcji kolekcjami niemutowalnymi jest moim zdaniem mało sensowne - no chyba że w celu umożliwienia efektywnego przetwarzania wielowątkowego.

Jesli zobaczysz, ze cos ma za duzo modyfikacji to po prostu uzywasz jakiegos buildera/mutable kolekcji.

Dokładnie. Jeśli coś trzeba najpierw zbudować, a potem się to coś nie zmienia to można właśnie użyć kolekcji mutowalnej jako budowniczego. Przy czym budowanie niemutowalnych list łączonych jest tanie - tylko zmiana nie na początku i ogólnie dostęp nieliniowy jest kosztowny.

Sam nie jestem jeszcze doświadczony w nietrywialnych projektach w Scali więc też nie mam dobrej intuicji nt tego kiedy użyć jakiej kolekcji.

Ale czy to jest na komputery, z których korzystamy, czy na szybsze komputery przyszłości?
(...)
Ale mam wrażenie że w tej chwili funkcyjność to dodatkowa warstwa abstrakcji która tylko ułatwia życie programiście a utrudnia komputerowi.

Mam podobne wrażenie. Ale moim zdaniem szkopuł tkwi bardziej w języku/ bibliotekach/ kompilatorze/ maszynie wirtualnej niż w komputerach jako sprzęcie. Najrozsądniej by było, gdyby wszystkie kolekcje zachowywały się tak jak kolekcje niemutowalne, natomiast kompilator/ biblioteki/ maszyna wirtualna wykrywały kiedy dana kolekcja jest wykorzystywana tylko w jednym wątku i stosowały optymalizacje polegające na dodaniu lekkich, mutowalnych, szybko aktualizujących się struktur pomocniczych lokalnych dla danego wątku na czas lokalnej operacji jednowątkowej zmieniającej kolekcję.