I was writing a small but semi algorithm-heavy library in C# that didn't rely much on other libraries. I later decided to port it to Java and realized that the more C#-like I had written the original code the harder it was to port. Later when trying to port it to JavaScript I ended up re-writing the C#/Java code to rely less on the standard libraries since each standard library differed so much. At that point my code started to look very procedural in the OO languages possibly similar to what you've been doing in Java.
I came to the realization I didn't even need a lot of the language features for what I was doing and decided to switch it to C to not have to maintain various versions of the library and it was a steep learning curve but I've come to really enjoy the simplicity but powerful capabilities of C.
Thanks for sharing this, it's a great, succinct example of the journey many experience. You could flesh this out and post it on medium or something to get the ideas out there for discussion.
My preference recently for side projects has been imperative/procedural style of programming. I prefer it to OO and FP hands down. To me code is so much easier to read when you don't have clever abstractions everywhere, most code reads line by line and isn't trying to hide anything. I think there is a tradeoff between concise terse code you find in OO/FP that reuses other code vs the long step-by-step procedural code. For me personally I'd prefer longer code that is not reusing a bunch of other functions.
It's almost a weird paradox: OO/FP focuses on reusing code yet imperative/procedural code (ie: C) does not reuse code but is itself the most reusable code. You can't have your cake and eat it too I guess.
Reusable code may be not the best code. There is probably a lot of redundancy (cross-cutting concerns). Or alternatively, increased interface complexity, to the point where it's easier to just write a custom-tailored version of the code.
I still like to program in C and make my own thin abstractions / "runtime", tailored to the task at hand, and using only minimal dependencies. That way it's much easier to have only essential dependencies, not accidental ones. It's such a relief seeing a couple thousand lines of cleanly modularized C code compile almost instantly.
For example, by putting a char * into a struct definition a dependency on a more clever string type can be avoided. All that it takes is delegating memory management decisions to another place. Which is actually very beneficial, since most code shouldn't be concerned with mutation or especially allocation.
> I feel like I must find a work not related to computer science
I'm not sure if you've already tried this, but in addition to applying to jobs related to your side project I suggest applying to other jobs that have a lot more jobs available. My guess would be the number of jobs for mobile game dev might be limited and competitive and that would make it difficult when applying as a recent graduate. Web technologies whether for front-end or backend development are greatly in demand and are worth considering.
> iOS developers do not face a huge demand like they have seen years ago
This is an apt observation. The number of jobs are seriously lacking for Objc/Swift, I was lucky to do an internship in iOS but could never get into another interview after that for the bleak number of iOS jobs available that I applied to. I transitioned into .Net web development and I have been given a lot more opportunities since.
Also, Apple also has a way of creating a walled-garden for their developers. Some of the best practices back when I was an iOS dev involved Apple-specific technologies like AutoLayout constraints and CoreData which doesn't give as many marketable skills if applying to non-iOS jobs.
Interesting insight, I haven't expected that the iOS market is that down already. I hear from app developing companies that the entire app market on iOS is kind of stagnating.
I second this. The whole .Net ecosystem is built really well on object-oriented design principles and I've learned a ton about how DI/IoC and SRP/ISP designs get implemented since switching to C#. Additionally Code Contracts are really fun to experiment with to help you be more thoughtful in learning design by contract. If design skills are important C# is a great language to use for it. The only thing that bothered me at first when I switched to C# was the use of PascalCase member methods, outside of that one nitpick I've been very satisfied, C# is a solid language.
My son is a lot younger than yours with a different set of struggles (currently he's just preschool age) but he also appears to be completely normal to people who haven't spent a lot of time with him. He especially struggles with sensory processing and fine motor related tasks. We haven't got a firm diagnosis yet but hope to find out more from behavioral testing (neurological testing hasn't been able to give us any good answers yet) so he'll hopefully be able to qualify for disability. I'm also worried about my son's future, especially since a lot of people he might end up working with likely won't understand that just because he might not look like he has a disability doesn't mean he doesn't have one (I see this kind of ignorance all the time). Best of luck to you and your son, I wish I knew good answers to give you about these kind of struggles but this is still fairly new to me.
Yeah, it took years of therapy and testing before we were able to determine what exactly was going on. For some reason have names for his disorders makes things more understandable.
Not joking at all. Functional languages have a reputation for being hard to learn mainly because they aren't what most people learn initially (and switching paradigms is never easy, no matter which direction you're going.)
Disclaimer: The above is an opinion. Double-blind trials have not been performed!
I agree that switching paradigms is not easy. The part that sounded like a joke and still sounds like a joke is downplaying the difficulty it is to learn OO abstractions and patterns. Even initially being taught them, does not mean you've really learned nor understood them well. When comparing it to something "elementary" I'd expect something simple like 13+4, not something as complicated as software design.
Nothing we do is easy for most people... that's why we're highly sought after.
What I meant was not that it's easy to do something, rather that it's something that often comes early, and is mandatory, in your journey of discovery. The concepts you learn early on, while not easy to fully grasp, stick, and make other paradigms seem alien.
What if learning "how to study" is just a way to distract yourself from learning the material? Finding a learning process might sound more fun and creative, but more than likely it will be a big waste of time. Fortunately, what you'll be learning from your study work is more likely to be useful and more fact-based than learning how to study, which is primarily opinion-based.
If I was to create a study guide I wouldn't tell the student anything they should be doing, but rather ask questions that lead them back to their source material:
* What are you learning about currently?
* Why do you find it challenging?
* Why is it important?
* What is the general idea?
Learning by applying some memorization technique sounds boring to me, in comparison to curiosity-based learning using socratic/thoughtful questioning. Instead of responding to study work with a fight-or-flight response, asking questions allow you to break out of that fearful mindset and start to examine the topic and as you ask questions about it you'll start to find little bits of interesting knowledge in it.
I do a lot of back-end web service work and I really enjoy using unit test debugging, it's really fast and gives you a good clean starting point. The times that I have to hook up the debugger to the web server to debug against the website in the browser can be really frustrating and a lot more work especially since the client-side code will call out again to retry web api calls that took too long. I'm yet to find an effective way to debug in this way without deleting breakpoints that get hit and then assigning new ones (and who knows which call exactly I'm debugging but since the data is the same it usually doesn't matter). Does anyone have a better way to debug than the way I'm describing, I use Visual Studio and haven't found a way to easily limit it to just the first call attempt?
I came to the realization I didn't even need a lot of the language features for what I was doing and decided to switch it to C to not have to maintain various versions of the library and it was a steep learning curve but I've come to really enjoy the simplicity but powerful capabilities of C.