Joined: 10/6/2011
Posts: 1697
Location: RU · ID · AM
Well, this post is not actually coding-related (I think), but I’m posting it here, because I think it may be interesting to someone.
A few days ago students of a major Russian university saw this announcement:
It is well known that job invitations from IT companies often present some challenges to solve, but at this time noone could find any solution. The announcement seems to be written in some kind of artifical language. Tens of people are already trying to solve the quest here and they suggest some ideas. For example, some of them beleive 1920–1978 may mean 1902–1987.
Anyway, hopefully this interests someone. Of course, it can be simply an April’s Fool Day joke, but… Who knows?
S3&A [Amy amy%] improvement (with Evil_3D & kaan55) — currently in SPZ2
my TAS channel · If I ever come into your dream, I’ll be riding an eggship :)
It reminds me of some artificial language. Not exactly Lojban, but something.
Might be worth checking out the links at http://en.wikipedia.org/wiki/Constructed_language .
Then again, if this challenge was made to a wider audience, chances are some of them should already know about that language...
Joined: 3/18/2006
Posts: 971
Location: Great Britain
A few months later....
Python seems great for me. I have finally used it to build some actually-really-useful personal applications. The biggest was only 600 lines though.
I feel now that I want to explore another language.
However, still undecided... The problem is I don't actually know what I want. Since I'm doing this purely as a hobby the field is completely open...
I'm leaning towards C++, and so I may begin to work through Stroustrup's beginner C++ textbook. If it gets too difficult or tedious (aren't all languages tedious compared to python? :-p), I may bail and try C#.
My reasons for trying C++:
i. Compiled (different from python)
ii. Cross platform (I want to build a client-server application for my linux server + windows client)
iii. Manual memory management (I should probably at least try)
iv. Visual Studio is apparently the best thing since sliced bread.
My reasons for trying C++:
i. Compiled (different from python)
ii. Cross platform (I want to build a client-server application for my linux server + windows client)
iii. Manual memory management (I should probably at least try)
iv. Visual Studio is apparently the best thing since sliced bread.
For II, Python is cross-platform, in the sense that the code you write on one platform will work on another (barring certain exceptions that are also problematic for any other language). If what you're thinking of is communication between computers, or between programs on the same computers (i.e. networked programs), then Python can do that, too.
As for IV, pretty much every major programming language has at least one associated IDE that a significant fraction of its users will swear by, and another significant fraction will swear at. :) IDEs can save you some typing, and they can save time spent looking up what a function is called, what parameters it takes, etc. It's worth trying at least one, even if you eventually decide that you'll just stick with a text editor (as many do).
I definitely agree that it's worth trying a compiled language so you get a feel for what the compiler can do for you. Learning how memory management works will make you a better programmer even in languages that handle garbage collection for you...but it can also be a difficult task.
I'll add one other thing to reasons to try C++: learning to cope with pointers and references. Many modern languages gloss over how you're accessing objects; C++ does not. You'll learn a lot about how "computers actually work" by manipulating pointers directly.
In any case, good luck!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The way to program optimally in C++ is also quite different from other languages, even when those languages resemble it (such as Java or C#).
In Java, for instance, you just carelessly allocate every single object with 'new'. And with that language it's justified: You don't have any other option, but it's nevertheless rather efficient. In fact, Java is extraordinarily faster at allocating objects dynamically than C++ is (if you allocate like 100 thousand individual objects with 'new' in Java and in C++, you'll probably notice that Java does it like a hundred times faster or something like that.) Unfortunately C++ (and C, and any language that uses the C runtime) is still embarrassingly slow at allocating memory. (Also C/C++ suffers from memory fragmentation more easily than a competent Java/C# runtime.)
However, in C++ it's seldom a good idea to be allocating hundreds of thousands objects individually with 'new'. Not only is it slow, it creates a memory management nightmare. Your program usually becomes needlessly complex and inefficient. (There are contexts in which this is inevitable, or at the very least the best solution design-wise, but that's not even nearly always the case.)
When you do it "right" in C++, you'll actually notice that your program not only becomes more efficient, but safer, simpler and easier to understand and follow, with less chances of memory management errors.
Knowing and understanding all the good principles, however, requires studying and experience. It's not a trivial path.
The biggest challenge with C++ is getting memory management right.
A lot more goes into the design and testing to get memory management right than other languages. You have to consider object lifetimes and ensuring no cycles. Then you also have to consider sharing data between different threads, async tasks and data structures.
Ensuring object lifetimes does not mean remembering to free what you allocate, but rather that your objects do not disappear before you are done with them. This is typical when you use threads and async tasks, because you have to carefully consider some things.
First, when you use threads or async tasks, you have to consider - do these tasks need some variables from the enclosing scope? If they do, then which ones? And then you have to consider how to share this data. Can you get away with simply copying the data to the tasks? That's the easier solution since you don't have to manage lifetimes or access (i.e. locks, etc).
Otherwise you have to consider if the tasks will outlive the scope of the parent function. If it doesn't, you can just create references to these variables because you can guarantee that they won't be destroyed before the tasks end (because the parent function won't end before the tasks do). If the parent function can end before the tasks, then you have to consider sharing the data through shared pointers. But that gives you the fallacy that you must remember to copy them properly. Creating references to shared pointers is a big no-no.
So you have to be mindful of:
- Do tasks in your function require variables from the enclosing scope?
- Do the tasks end before the parent function?
- Did you properly capture the variables from the enclosing scope?
To make things a little more complicated, you have to consider what can be copied and what can be moved. Some things, like file streams, can only be moved because it usually makes "little sense" to copy a file stream. When you put such an object into a data structure, that structure becomes move-only, and you have to reflect this in your code. Moving local variables can also result in putting moved-from variables into undefined states, which makes you responsible for not using them afterwards. Additional complications arise when you need to capture move-only variables into tasks.
Then you have to consider sharing between data structures. Usually we copy objects because it's easier and more cache friendly. But if you need some data to be up-to-date in several data structures, you need to share that data. Then you have to consider at what granularity you want to share the data. Share absolutely only what is needed or share its parent object, for example. Again, you have to be mindful of the object lifetimes, as copying a shard pointer incorrectly will result in the data it points to being freed prematurely.
Then you also have to consider what happens if you screw up. You considered the sharing, but in reality, there is a bug that causes it not to happen. How do you track it down? How do you detect it? How do you know it's there? How do you know you've correctly managed lifetime scopes of objects?
Finally we have circular references. This occurs in typical structures as linked lists. You have to identify where they may occur and detect that they do not happen because it will leak memory.
It sounds easy to just put a shared pointer in a data structure and be guaranteed it will work, but that's just far from the case. C++ can be scary, but it also gives you a lot of power and speed. If this doesn't frighten you, then you're welcome to study C++. It's not always easy - but then again, the life of a programmer is rarely easy. It's not for the faint of heart, but if you choose to do it anyway, then best of luck to you.
Ensuring object lifetimes does not mean remembering to free what you allocate, but rather that your objects do not disappear before you are done with them.
This seems to assume that you need to allocate objects individually with 'new'. That's not even nearly always the case.
Nope. Not necessary.
Just put a local variable on the stack, capture it in a lambda that you pass to a thread. Now you have to worry about the lifetime of the local variable.
Is the lifetime of the local function going to outlive the lifetime of the thread? If so, a local variable is fine. You can even capture by reference. It is the reverse? Now you have to worry about it. If you capture by value you have to consider if the variable CAN be copied, if it's expensive to copy and if the local function needs state from the variable. If you can't capture by value, you have to consider allocating on the heap. Then you have to be wary of capturing it right. Capturing it by reference is bug. But also by allocating on the heap, you have to consider the overhead of heap allocation.
Well, yes, that's true, but you're going to get there, eventually. Async tasks and threads are all the rage right now. This is just a detail of C++'s memory management complexities. If you're just doing very small toy programs, you won't encounter much of the complexity of any language.
Remember that all languages have quirks. In garbage collected languages, you have to more mindful of when objects destruct since that can release critical resources such as file handles, etc. I'd see it as a challenge.
It's not that scary. Some people just seem to have this... I don't know... obsession with allocating objects individually with 'new' (which is what causes memory management issues in C++). But the thing is, in a good portion of cases you'll never need it. (Naturally it's good to know, but it's not something that comes up all the time.)
Problem is that when you start working with basic libraries (i.e. networking), you're going to run into async tasks. Async tasks are also present in Microsoft's C++/CX. Simply put, it's becoming more and more common, and as such, it is a good idea to learn how to do it.
But the thing is that async tasks really forces the complexity of memory management to surface. I agree, if you're just doing hobby programs without threads and async tasks, you're not going to run into much problems managing lifetime, but you are going to have to think about what to share between data structures.
It's a necessary evil for now.
I spent the last two days working on a little platforming game in javascript/html5.
http://i.imgur.com/uvuPiuk.pnghttp://www.file-upload.net/download-10118986/platformer.zip.html (the download link may expire in a few months, if lurkers later want a reupload then pm me)
To open the game, open the .html file. The debugging stats are enabled, so if you want to disable them, change the "debug" boolean to false inside the .html. This is nowhere near finished obviously.
This is pretty much the first time I ever did something like this. This page was of great help, I just copy pasted from there and changed how I saw fit and now look where I am. :)
I'm really thrilled to add more things to my game. I was actually thinking about adding items that you can pick up and then use (ropes that you can climb down for example), bridges that shake when you walk on them, enemies, collectibles, NPCs, ... there is no limit. The only limit is my daily time and energy.
https://www.youtube.com/watch?v=TC9zhufV_Z8
I may not get a "good" reaction for this, but... here goes anyway.
Please stop using javascript. It is literally one of the worst programming languages out there that was not designed to do anything but basic scripting.
Here's a link ta a tutorial with C++. Very easy to get started.
Thanks for the link but I'm not going to stop what I started despite how horrible you say javascript is. I have some high plans and I'm curious if I can realize them. This is going to be just a hobbyist project for now, and a pastime since I barely have stuff to do at my work.
In the school that I attended last year we were taught Java and it was very frustrating. The teacher wasn't doing a good job and the problems/tasks given to us were confusing, we were given too little time or I was not motivated. With Javascript, since it's close to web development and crafting websites, I feel a lot more comfortable and I can see results of my code very quickly. I'm going to have to attend this school again around August this year for more Java and it's going to be about databases; I don't know if I'm looking forward to it.
Well, I mean, it's your choice. I'm just saying that if you take some time into learning another language such as java or C++, it will make your life much easier when programming.
https://www.youtube.com/watch?v=TC9zhufV_Z8
I may not get a "good" reaction for this, but... here goes anyway.
Please stop using javascript. It is literally one of the worst programming languages out there that was not designed to do anything but basic scripting.
Here's a link ta a tutorial with C++. Very easy to get started.
The thing is, javascript can be run with a browser, and easily display something on screen. And this requires nothing more than a text editor. Everything else is already in basically every single computer in existence (regardless of OS).
C++ is certainly more powerful and versatile, but the initial setup you need to get anything on screen is quite large, especially for someone who has never done that nor doesn't have any kind of environment for it set up already. Also, the result you get is an executable binary which will run only on one system, needs to be downloaded and run, and like all native applications, has slight security risks involved (catastrophic bugs, viruses...) Javascript running on a modern browser is almost as safe as you get (barring some browser bugs). It's really slow, of course, but safe.
I have been programming for years games for iOS as my payjob, so I have some experience on that front. (I absolutely love being able to use C++ for this, as it's my favorite programming language. However, I recognize the hurdles that a beginner will meet the first time. They are quite big.)
I realize C++ may not be the best tool for the job for a beginner. That said, I'm a bit biased and I knew of a tutorial that created a simple C++ game very quickly and with very little code and with little complexity, so I just recommended something to get away from javascript. There are probably better tools for beginners, though.
I realize javascript is great to get started, and the performance is good enough for small games, but the problem is that it really sucks when you start doing something more complex. Javascript doesn't even have the concept of a class and you can't even tell javascript to check that you're accessing properties you've created instead of accessing inexistant ones. It isn't even compiled, so you have to run the code and test all paths to find a lot of common problems.
So yeah, in the end, it is much better to transistion to a strongly typed language to do programming in, even for simple games. That's the reason I mentioned that.
When I was briefly in college for computer science, javascript was the first programming class on the list. It was required as part of the degree. Luckily, I left before I learned anything.
I realize C++ may not be the best tool for the job for a beginner. That said, I'm a bit biased and I knew of a tutorial that created a simple C++ game very quickly and with very little code and with little complexity, so I just recommended something to get away from javascript. There are probably better tools for beginners, though.
As someone who writes games in C++ for a living. I agree that you can write a very simple game very swiftly using C++. But you invariably cause yourself mountains of headaches down the road if you're looking to do something more than "toy project" status.
I recommend python for simple projects. There's an entire library for games called PyGame.
If I had to do it all over again, I'd probably choose Haskell for my big project. But that's not really suitable for beginners either? Unsure.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Honestly, if you want to make games, download Unity and go through some of the tutorials. Unity's a professional-level game engine, but it's free (for any developer making less than $100k/year from their Unity products, which I guarantee will include you for the foreseeable future) and has a ton of community support.
There's a lot of really hard problems in game development that have been solved a million times before. It's not really worth solving them yourself except as an exercise. Here I'm talking about stuff like resource management, physics, input handling, 3D scenes, animations, etc. etc. etc. I made my own 2D sprite-based engine once. It took me months. If I'd used a full game engine (as opposed to the SDL, a.k.a. PyGame, which is what I used), I could have spent that time on content and maybe actually finished my project.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Unity is a good solution. It can build for numerous different platforms, including html5.
You will, however, be basically limited to either javascript or C#. I would definitely recommend the latter, as it's more versatile and efficient, and not all that different from C++. It doesn't have everything that C++ has, but on the other hand it has some things that C++ doesn't, but they are very similar. If you are an experienced C++ programmer, you'll know how to program in C# with extremely little effort (but unfortunately not in the other direction.)
You can write plugins for Unity with other languages such as C++ (which is great if you need some subroutine that's absolutely optimized for speed and/or memory usage), but I'm not sure how well they integrate (compared to the native C# support). Also, I think that being able to write plugins with other languages requires the pro version of Unity.
It is well known that job invitations from IT companies often present some challenges to solve, but at this time noone could find any solution. The announcement seems to be written in some kind of artifical language. Tens of people are already trying to solve the quest here and they suggest some ideas. For example, some of them beleive 1920–1978 may mean 1902–1987.
Anyway, hopefully this interests someone. Of course, it can be simply an April’s Fool Day joke, but… Who knows?
