(I really have no idea about what the impact of that thing was, but when I see Twitter exploding about it, and then you mention it, I wanted to at least make sure you had ruled it out.)
NOPE! It wasn't a path issue! It was the fact that my bash profile was not run by default, so despite the fact that the requisite source line was in there, it didn't run. So RVM wasn't properly set up in fucking bash. So it couldn't use the right rubies even when I explicitly was telling it to. BUT IT DOESN'T TELL ME THAT, NO, IT JUST SHITS ITSELF. FUCK YOU RVM BY RVM.
So I've been 'researching' TBS games, and started thinking about how Steambirds does it's line. What equation are they using to draw that line, and how are they limiting the curve to the turn radius of the plane? EDIT: Hmm thinking about it further, they are probably using any old curve equation (my fav is catmull rom), and just making sure the end point doesn't lie within one of the turn radius circles, and if so have the endpoint lie on the outside of the circle.
Sangry web developers, I summon thee! I have been developing (mostly personal use) webtools in PHP for over a decade and am pretty darn good at it. But the language is kind of long in the tooth and its core was developed on older design principles/methods in computer science, so I'm thinking of making the switch to Ruby which seems to be the hot shit these days. But I know almost nothing about Ruby except the very basic ideas (everything is an object, etc). There's nothing on my plate right now but I would like to start writing some new stuff say one year from now; not for a paycheck but just for my own projects. What is the current state of the web development hivemind: stick with an older language that you know (PHP) or spend the time to pick up something new (Ruby)? Is Ruby fairly straightforward for a reasonably competant PHP coder to learn? Alternately, is there a third language candidate that is making even bigger waves? eta: To clarify, this would be for developing fairly complex projects. eta 2: actually fuck all that, the new question is now: Python v Ruby? (the less religion, the better kthx)
Sadly not true. The original designers of PHP had no idea what they were doing and really mostly lucked into the good decisions they did make. The current designers aren't a whole lot better. PHP is an awful awful language and I highly recommend looking into something else if you aren't required to continue using it. Ruby's a good option, as is Python (which is almost the same, on a language level). Ruby on Rails is the primary web framework used with Ruby, and I believe Django is the primary Python web framework. Node.js is another option; it's a server framework that runs JavaScript. Weird, I know, but it's got some neat ideas and has apparently been getting some adoption.
Python would be the obvious third language candidate; Python and Ruby sort of fill the same niche in the web development ecosystem. I looked into both of them last year for the same reasons you're listing. They're both dynamically-typed languages which have popular, well-maintained open source web frameworks (Django for Python, Ruby on Rails for Ruby). Neither language is a speed demon, but you don't need that for most web development. Both of them, when used well, can let you do a lot with only a few lines of code, and both of them are (IMHO) much more pleasant to work with than PHP (which is the only language I've ever liked less and less the more I used it). In the end, I went with Python for two reasons: 1) Python seems like it has more of a presence outside the field of web development. Ruby is big (huge!) because of Ruby on Rails, but it doesn't seem to have penetrated other areas of programming very widely. In contrast, Python gets used in other fields (mathematics, vision science, etc). That appealed to me. 2) I found code written in Python to be aesthetically pleasing; concise and exceptionally easy to follow the train of thought as you move through the code. Ruby syntax is concise, but it just didn't strike me as beautiful. This is obviously a purely subjective judgement, and there are plenty of Ruby users who have exactly the opposite feeling about Python code versus Ruby code. I don't think you can go wrong with either language if you're focused on web development.
I definitely agree with encountering Python outside web development. As a non-web developer, I've run across it a few times =) I've never encountered Ruby though.
Yeah, python isn't primarily aimed at the web it just happens to be a decent scripting language that lends itself (via Django or other frameworks) to working with webapps. Until recently 100% of my python programming was back office batch jobs, ETL tools, a few odd daemon processes that were easier to write in python than C, and other assorted non-web stuff. Heck, my recent minor foray into HTTPville was really only to add HTTP APIs using bottle/cherrypy to some existing python applications for integration purposes. Also, node.js is the devil and should be avoided.
You've kinda missed my point. A forum-anecdote that the designers didn't fully grok === doesn't go against my point. Thus this question was posted. ... Ooooh yeah, Python. As a type-A personality, enforced indentation actually excites me (mah nipples!) and I'd played with it briefly about six years ago. Damn. OK, so editing my original question: what are some anecdotes on the Python v Ruby tip?
They're almost the same language with some different keywords, truth be told. It's similar to the whole Java vs. C# thing. Edit: For whatever it's worth, I think local startups tend to use Ruby on Rails more than the assorted Python solutions.
Just because I'm "that guy" I'll throw out a third option. Groovy on Grails. Groovy is a java-ish scripting language that runs in the Java Virtual Machine and Groovy on Grails aims to do about the same thing as Ruby on Rails only in a java environment. The advantage to that can be quite nice as groovy on grails projects can just jump into an existing java application server based deployment without requiring new application servers or major reconfigurations. If forced to choose between Python and Ruby I'd go Python but only because it's a more popular language with a richer set of third party tools. From what little experience I have with Ruby I'd say there's nothing to really object to.
F you all. I'm writing server-side code in C++ compiled into the webserver! SPEED YOU ARE MINE. Oh wait, I'm running on a 375Mhz ARM with no floating point. SEEYA LATER SPEED.
For web stuff, I think Node is super-compelling. Any modern website is going to have a ton of client-side JS, and it's a lot simpler to just stay in the same language end-to-end. And Express is a great web framework -- minimalist, but abstracting just the right things.
Here is a favorite post of mine from 2003 by Alex Martelli, a big name in the Python world, where he compares the two languages. The takeaway lesson is that the two languages are very similar indeed, moreso if you're adept at ignoring "mere" syntax differences, and the biggest differences will probably come down to community and philosophy. In the end, Martelli does give the edge to Python, due to its marginally less dynamic nature. I would also emphasize the point that Python's community and selection of third-party (particularly non-web-related) libraries are greater.
It looks good on paper but my real-world experience with node.js is awful. It's just not ready to be a robust server-side solution. One of the biggest problems is simply that javascript has never been a server side language so all the skilled javascript programmers I run into know nothing about writing decent server side code. Writing a daemon process has a whole different set of environmental challenges than running a browser sandbox.
I've been using it (for some personal things, not work things) and it's worked very well and reliably for me. I do agree about skill sets, though. Node is unique enough that people who just try to jump into it from, say, a PHP/jQuery background will probably make huge mistakes. Still and all! I really like it, and find that I can do things in a way that's simultaneously quick and clean and which doesn't involve a ton of code.
Any embedded programmers here that work in the industry? I'm just trying to figure out if there is a fairly standard or reference ARM eval board based on Linux or a similar multithreaded OS (and with an Ethernet stack). For prototyping and playing around as a hobbyist I'm aware of Arduino (which is too low end for my needs) and Raspberry Pi (which is aimed at hobbyists), but I'm looking for something that is used commercially.
Look at LogicPD. Their core modules can be dropped on a custom baseboard that can be very simple. edit: Other nice things: 1) Industrial temp range available 2) Linux BSPs 3) BSPs for other OSes also available 4) Their custom bootloader is is pretty nice 5) They're meant to be bought for production, eval boards right from chip manufacturers tend to disappear after a while.
We have done a few small projects and we're starting to get more serious about it. Right now I'm playing around with an Atmel AT91Sam9x35 EK (evaluation kit). I'm not really a hardware guy, so I don't have anything useful to say about it other than the hardware guys at my office like it. I'm gonna install an OS and try to get some code running under mono today. Go and python are other options for us. I'm the only one here with any C experience, so we're probably not going in that direction unless performance becomes a factor.
Ross, Be careful using scripting languages, or hell, any language at a higher level than C/C++ for embedded projects. Python interpreters are a rarity on embedded devices and embedded OSes, and if you want to do a cost reduction and go to a smaller, cheaper platform in the future, it'd be a shame to have to recode everything. Embedded space is not "let's use the most productive software tool I can!", it's "let me find the balance between the hardware and software that meet the overall system requirements". Usually that means you're writing in C or C++. Sometimes it means you don't have an OS. Sometimes you've got a horrible PIC and are writing ASM.
It's funny, given my history, you would think I'd gravitate toward Ruby. Perl was one of the first languages I learned, and I loved it. I did not love coming back to a perl program after several months (or years) to find I had no idea what I was looking at. Debugging hacked-together perl programs is just a nightmare. Don't get me wrong, I think perl can be a great language when used effectively, but my tastes over the years have changed and I found myself drawn to Python. Nowadays, it's my language of choice, especially when I need to do quick-and-dirty automation tasks. Then again, I've spent most of my career writing code in MUMPS, so anything looks like an improvement from there.
You know what? Everybody pokes fun at MUMPS (including me), but it's got a few things going for it that I think are brilliant (and poorly represented in other languages): Completely integrated multidimensional arrays, both local and persistent. Speaking of persistence: the global storage system is blisteringly fast and efficient and I've not seen the like in any other language. Iterating quickly over vast amounts multidimensional data is stupid easy. Of course, the list of things I hate about it could fill a book (or ten.) :(
Yeah, I'd want to echo this as well. The performance delta between C/C++ vs. Python/whatever on a 3GHz machine is irrelevant, but it gets really sketchy down into the hundreds of MHz area. I saw someone posting about how he was trying to write a synth in Mono for Arduino and couldn't get a waveform faster than about 40Hz (which...isn't really audible). Switching to C he saw a 1000x speed boost. The overhead of a run-time, GC, interpretation, etc. suddenly becomes a dominant constant factor. One thing I really like about Arduino programming is that the scale of the software is much smaller, so I tend to have a very strong mental model in my head. This means that my code is more correct and easier to debug because failure cases are obvious (even without having a debugger). Whereas on a 100K or 1M line code base, the relationships are hazier and blow ups can be multiple levels of indirection away from their actual point of failure. I also tend to write simpler but less elegant code when I'm space constrained (e.g. I do linear searching instead of trying to introduce a theoretically better binary search), which is almost always a win on smaller, simpler projects. That said, sizeof(int)==2 and only having 8K of RAM takes some getting used to. I can't just randomly drop Code (text): char buffer[1024]; everywhere anymore... Oh, and everything being single threaded greatly reduces the complexity. And not having an OS get in your way also reduces the second guessing. I really do enjoy Arduino programming =)
I'm going to say that this is generally true of ANY embedded project, the smaller scope of it just makes it more fun. My codebase is <50K of C++. Sure, that's approaching the "oh, I already wrote that function (but forgot about it)" size, the fact that it's a bunch of varied modules doing varied things means that that my tasks at hand deal with a pretty small subset of the entire codebase. Most every single problem I run into I can find by just staring at the code for a bit. I'll drop into the debugger every now and then to help me figure out what I really f'ed up, but I'll just resort to printf() debugging every now and then. printf() debugging is sometimes really needed too, because I find that gdb-based debuggers, at least, tend to have erratic performance when running over an Ethernet link to a cross-compiled target. Then I throw a template in there and gdb, or more specifically, CDT gdb front-end, just gets really, really confused. What you say, writing templates for embedded systems? = Heresy! Nahh... with something like those LogicPD ARM systems up there, my embedded device has more power than the computer I had in 2000, and I'll take compile-time correctness over void* casts or #defines anyday.
I'm working on a device with a multi core processor clocked in GHz with multiple GB of RAM and still occasionally get the "this is an embedded system!!!!" complaints because I used an STL container. Having previously worked on devices with single cores clocked in the ten of MHz with a few KB of RAM where doing a divide outside of a load sequence was highly questionable I laugh at them.
I do admit that I feel a pang of wastefulness when I use something other than a vector reserve()ed to a good size or use a std::string, then I realize that it's in my GUI update loop that runs at 15Hz on a 800Mhz processor, and that it will be OK.
Thanks guys, I really appreciate the input. I will say that I am mostly doing due diligence in evaluating languages/platforms because there is some disagreement among my coworkers about it. As much as I dislike C++, it was my initial suggestion before we decided to spend a little time trying things out. But if Mono will do for our applications, we'll certainly be going that way since we're a C# shop primarily. The decision isn't really mine to make.
If you want a scripting language that embeds easily, consider Lua. It's super fast, and can run with low overhead. We used it on MDK2 dreamcast, without even compiling it (just interpreted text), and that was a system with a 200mhz risc chip and only 16mb of ram.
I sure hope you don't have any sort of real-time or high performance requirements, because that Atmel is a 400Mhz ARM926, with no floating point unit. It's going to be poky as shit running interpreted code. And don't take this the wrong way, but a shop that's primarily C# strikes me as a shop that really needs to be careful about picking embedded hardware. :) Benchmarking is your friend!
If you're going to be running a standard Linux distro on it, or you want to do something that's doing serious JITting like Mono or a JavaScript engine, then I definitely recommend an armv7 core (that is, a cortex-a8 or better). Firstly, there is an ABI binary compatibility break there (where for newer cores the calling convention assumes an FPU) and secondly the people testing and fixing performance issues on complex architecture dependent code like JITting engines will all be using v7 cores rather than previous-generation hardware. If you're still doing old school "we hand compile every binary that goes onto the target" style embedded development this is less important. You should probably also favour board/soc vendors that seem to have their act together about getting their driver code into the mainline kernel if you care at all about being able to upgrade to newer kernels in the future.
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE Well, Lua is definitely not an option then. Everything numerical is a float in that language.
Kids these days.... If you edit luaconf.h and redefine LUA_NUMBER to int (and a few other associated macros) it should work without floating point (except you obviously lose floating point operations, but that's not something you're really going to be doing much on a microcontroller).
True enough, but I would potentially worry about how the language would handle everything being ints, especially since you could type out a float in a script. Hrm... perhaps I'll play around and see what happens if you actually do this.
Also I take exception with your 'kids these days' statement, since one of the first engines I made as a programmer was a fixed point software 3d rendering engine. But time moves on, and working without floats these days is decidedly archaic.
Dude, it was a joke. I apologize for the lack of emoticon. Life without floating point is definitely rarer, however if you code low level embedded stuff then floating point is often still not available. I guess my bigger issue is the notion of trying to run these extremely high level languages on something that is designed to be as bare as possible. My Arduino Mega is relatively beefy and still has only 8K of RAM (shared by heap and stack and strings!), and people still try to run Python on it, and manage to, then complain about the performance. In another forum I saw someone mention how he had to use a 120MHz controller to handle parsing and some timing for a project that should have been feasible on a 5MHz part...then it turns out he was trying to run C#/.Net on his design. Kids these days... =)
I had a embedded processor/OS that did floating-point operations really well. The code was compiled with floating point operations. When the processor encountered a floating point operation, it would throw a processor exception. This would get caught by the kernel, who would then call the software floating point library. Yup, a processor exception for EVERY floating point operation, increasing the time for the call to the soft-float by 100x.
There was a period where the kinda-standard ARM Linux calling convention (as used by Debian, at least) mandated the use of the FPA floating point registers for returning float or double results. Unfortunately the FPA was rare as hen's teeth, so the effect was that even if you compiled your code to use softfloat you *still* had to take an exception hit or two for returning float/double results...
