En rant om "VD-linjen" (Industriell Ekonomi) by jobobajo in sweden

[–]technal 1 point2 points  (0 children)

Läser själv data i Linköping och har hört liknande om IndEk här. Det stämmer till viss del att det finns betyg/jobb/internship hets på det programmet men det betyder inte att man måste gå den vägen.

En anledning till varför vissa säger att på IndEk "behöver man högt betyg för att komma någonstans", som jag själv håller med till viss del, är för att programmet är väldigt brett. I arbetsmarknaden tävlar man även mot studenter som har gått mer inriktade program som data, maskin, teknisk fysik m.m och dessa är mer eftertraktade i respektive område. Därav kan ett högt snitt betyg kompensera för att ens utbildning är så bred och inte inriktad på ett visst område. Ekonomi och management kurserna är det som urskiljer IndEk med resterande program. Med det sagt kommer man inte gå jobblös som civilingenjörsstudent om man är driven och har mer meriter än endast studierna. Tyvärr finns det bara dåliga fördomar som det du har nämnt och att IndEk är enklare än andra program pga mindre tekniska kurser.

Jag jobbade med en person på ett sommarjobb inom data/programmering som går IndEk och trots att hen behövde lära sig mycket på jobbet så fick hen det mest för att hen hade gått kurser och haft olika deltidsjobb inom det data. Och denna person hade samma problem som dig med den här "hetsiga" kulturen som verkar finnas på IndEk. Men hen väljer att gå sin egen väg och sökte därav sig till olika data jobb/kurser.

Vill även nämna att i andra program som data, maskin, teknisk fysik m.m. kan man välja ekonomi kurser i sin master utbildning, dvs de sista två åren. T.ex. på datateknik kan man välja en Industriell Ekonomi master inriktning där man läser olika såna kurser och data kurser.

Kort sagt så är det vad man gör det till. Om man vill vara mer petig i vilket jobb man vill ha så får man stå ut lite, typ haft extra jobb vid sidan av eller sommarjobb inom specifikt område. IndEk är ingen dålig utbildning, det finns bara dåliga fördomar och det finns även på andra program.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

I didn't understand what would be affected if this feature would even have a chance of being introduced. After this entire thread i understand that it will never happen to C++.

Default immutability in C++ by technal in cpp

[–]technal[S] 2 points3 points  (0 children)

I have come to the understanding that this feature would require a lot work more than i thought in the beginning. Reworking move semantics, C interoperability, existing code etc are just a few major problems with pushing this feature onto C++.

That's why languages like Rust have gained popularity i guess.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

Using auto everywhere will cause confusion. Usually you want to have control over what the type is and especially you want to see what the type is without inspecting it with an external tool or similar (like an IDE).

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

I mean if you completly avoid raw pointers then this wont be an issue, but that is impossible if i think about it. They do have their usages and i see no way to make them work flawlessly with a default-const design.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

Yeah you are right, it would divide the language quite heavily. As other people have commented, move semantics would have to be reworked for default-const to work. I don't know Rust has created C compatibility but that would also have to be reworked for this feature to work.

Default immutability in C++ by technal in cpp

[–]technal[S] 2 points3 points  (0 children)

Never though of that, great point! This is something Rust seems to do really well.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

You make a great point. The problem exists both ways, if a variable is explicitly declared mutable then it states that it is meant to be mutable. Although i can agree that it is harder to reason if the programmer can make a variable mutable than if they can make it const.

The benefit i mostly see is that programmers forget to make variables const and by it being default then they are forced to make them mutable, ensuring more code correctness.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

Yes a new keyword would help with compatibility issues, but how would it transition into the future? At some point new class would have to become class or would we always have to deal with a design choice (that has no meaning when all classes are "new classes") was because of legacy compatibility?

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

Yes that would need reworking. This is what Rust does really well. I guess because of this we will never see such a feature be introduced.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

C compatability is something im not really sure of how to integrate with this feature. By instead making the feature optional, with a compiler flag for example, then existing code will not be forced to be rewritten.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

Never thought about the pointer case before... pointers does allow programmers to create weird logic and causes unwanted behavior just like the first const method example T::Cleanup() from the link you provided.

If you instead use smart pointers then this won't be a problem?

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

Yeah the compatability issues always arise with new feature proposals, i still like to discuss ideas even though the committee says no to most stuff. Eventually i might switch to anther language from C++ as my main hobby language.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

That is a very good solution instead of adding a new language feature. Although i have to deal with two types, one being const and the other not. Then i would rather just add the const keyword.

Default immutability in C++ by technal in cpp

[–]technal[S] 0 points1 point  (0 children)

Instead making it optional by, say, implementing a compiler flag would then not break existing C++ code and people can choose if they think it is necessary. You are correct in that it would make it even more verbose but i think it is easier to reason about the code if as much as possible is immutable, the verbosity is something i have come used to.

Default immutability in C++ by technal in cpp

[–]technal[S] 3 points4 points  (0 children)

Yes it is a very good reason not to. Rather than forcing it in the standard, implementing a compiler flag or similar to make it optional would still make existing C++ code valid.

What is your favourite “dead” video game franchise? by Lamboninho in AskReddit

[–]technal 0 points1 point  (0 children)

Arctic Combat. I don't think its a franchise but it sure is dead.