This has been a nagging question to me for a few years now, and is part of the reason I stopped coding as much a few years ago, only to pick it back up again over the past two years: Just how useful is it to learn a programming language like C++? No, I'm not talking about python wrappers for it, or C#, or something "similar" like Java (and no, they are not similar like you may think). I'm talking about low level C++, down to the metal, with just you and your compiler (IDE optionally too). Had you asked me 2 years ago, I probably would have said C++ is just for gaming. Ask me now, and I'll tell you it is still one of the most relevant languages out there. Let's go over a few things about why C++ is a big deal, and why you should learn it if you don't know it.
Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts
Thursday, January 8, 2015
Wednesday, March 19, 2014
Kinecting Back to Blogging
It's been about two weeks since my last blog post, and so I figure I should make this particular post about what exactly is going on. Back in December, I applied for the Microsot Kinect for Windows Version 2 alpha. In February, I found out that I was accepted, and went ahead and got the sensor as a birthday present to myself. Finally, when my spring break started two weeks ago, I got the chance to sit down and fiddle with the hardware, and I've got to say, I am impressed so far.
So for today's post, I'll be going over how to use the Microsoft Kinect for Windows V2 APIs in C#, and the process of making a simple application. The code for this will be presented at the end of the article, so if you're just interested in getting the code, just scroll down to the bottom. There's a bit to this project since we'll be using multiple data streams, but hopefully not too bad. Before I continue on, I do want to stress that this is preliminary software and/or hardware and APIs are preliminary and subject to change.
So for today's post, I'll be going over how to use the Microsoft Kinect for Windows V2 APIs in C#, and the process of making a simple application. The code for this will be presented at the end of the article, so if you're just interested in getting the code, just scroll down to the bottom. There's a bit to this project since we'll be using multiple data streams, but hopefully not too bad. Before I continue on, I do want to stress that this is preliminary software and/or hardware and APIs are preliminary and subject to change.
Monday, February 10, 2014
High Level Tools Versus Low Level Coding
As someone who is constantly trying to hone my technical abilities, I look around at what tools other people use when developing all the time. I've noticed a very big trend right now with using tools such as Unity or UDK for game development for example, or tools like the Titanium Mobile Development Kit for creating a simple mobile application. This even extends to a lower level though when coding, such as using GLFW when creating a window in an OpenGL program, or using a 3D library for Javascript instead of just WebGL.
Why these tools are chosen instead makes sense though, as developing a lot of these on your own would take a ton of time away from just making your application. Just creating a window to use with OpenGL is incredibly time consuming, so why not just use an external API to do it for you? Especially since these tools will allow you to go cross-platform automatically when done correctly.
Yet I constantly wonder about whether these tools are good or not though. I believe using these tools takes a way a huge part of learning to code, because you suddenly don't have to worry about what's happening behind the scenes. You start trusting that these tools are doing the best they can at whatever you are expecting them to do. Is this a bad thing though? On the one hand, it allows for developers to focus more on developing their applications, and less dealing with bugs in code. On the other hand, if a bug comes up in the tools, they may have no idea how to fix it or get around it properly.
These ideas bring in another concept too though: are you learning how to code, or are you learning the tools you use? Going one step further, should this count as coding, or should it count as something else? If you use an entire drag-and-drop IDE, should that be considered coding or does there need to be a new category for this specifically? I think a lot of these questions honestly come down to opinions and what exactly you are making with these tools. How much are you using from others, how much are you making yourself, and if you run into a problem, can you solve it, are some of the important factors that I think should be considered.
I don't consider myself in any place to judge on whether it's more important to learn more about using tools or how tools work, but I do think it's something that should be brought up. Me personally, I like to learn how the tools work, and then apply those uses when I use tools. This leads me to do a lot of unnecessary work, but I feel confident about what I am learning as a result. Does this mean that you can only feel confident this way? Of course not. This is just my personal preference. That being said, what are your preferences? Do you prefer just diving into making your application, or do you like learning what the code behind the scenes is for your tools?
Why these tools are chosen instead makes sense though, as developing a lot of these on your own would take a ton of time away from just making your application. Just creating a window to use with OpenGL is incredibly time consuming, so why not just use an external API to do it for you? Especially since these tools will allow you to go cross-platform automatically when done correctly.
Yet I constantly wonder about whether these tools are good or not though. I believe using these tools takes a way a huge part of learning to code, because you suddenly don't have to worry about what's happening behind the scenes. You start trusting that these tools are doing the best they can at whatever you are expecting them to do. Is this a bad thing though? On the one hand, it allows for developers to focus more on developing their applications, and less dealing with bugs in code. On the other hand, if a bug comes up in the tools, they may have no idea how to fix it or get around it properly.
These ideas bring in another concept too though: are you learning how to code, or are you learning the tools you use? Going one step further, should this count as coding, or should it count as something else? If you use an entire drag-and-drop IDE, should that be considered coding or does there need to be a new category for this specifically? I think a lot of these questions honestly come down to opinions and what exactly you are making with these tools. How much are you using from others, how much are you making yourself, and if you run into a problem, can you solve it, are some of the important factors that I think should be considered.
I don't consider myself in any place to judge on whether it's more important to learn more about using tools or how tools work, but I do think it's something that should be brought up. Me personally, I like to learn how the tools work, and then apply those uses when I use tools. This leads me to do a lot of unnecessary work, but I feel confident about what I am learning as a result. Does this mean that you can only feel confident this way? Of course not. This is just my personal preference. That being said, what are your preferences? Do you prefer just diving into making your application, or do you like learning what the code behind the scenes is for your tools?
Saturday, February 1, 2014
One PC, Three Kinects
Recently I managed to get a hold of three Microsoft Kinects. A few of my family members had one (including myself) and ended up not needing them since they never used them. Being the "techy" I am, the first thing I did was attempt to integrate them into my recent Oculus Rift projects. While the code seems to be correct, there was an issue from a hardware perspective that I was hoping to not run into. Alas, I have, and thus am writing this blog post about what exactly is going on. It's an interesting little hardware problem that I'm hopeful Kinect 2.0 will solve a bit more, and that'd I decided to do a quick write-up about.
Subscribe to:
Posts (Atom)