Nerval's Lobster writes As developers embrace new programming languages, older languages can go one of two ways: stay in use, despite fading popularity, or die out completely. So which programming languages are slated for history's dustbin of dead tech? Perl is an excellent candidate, especially considering how work on Perl6, framed as a complete revamp of the language, began work in 2000 and is still inching along in development. Ruby, Visual Basic.NET, and Object Pascal also top this list, despite their onetime popularity. Whether the result of development snafus or the industry simply veering in a direction that makes a particular language increasingly obsolete, time comes for all platforms at one point or another. Which programming languages do you think will do the way of the dinosaurs in coming years? With COBOL still around, it's hard to take too seriously the claim that Perl or Ruby is about to die. A prediction market for this kind of thing might yield a far different list.
An anonymous reader writes: Rosetta Code is a popular resource for programming language enthusiasts to learn from each other, thanks to its vast collection of idiomatic solutions to clearly defined tasks in many different programming languages. The Rosetta Code wiki is now linking to a new study that compares programming language features based on the programs available in Rosetta Code. The study targets the languages C, C#, F#, Go, Haskell, Java, Python, and Ruby on features such as succinctness and performance. It reveals, among other things, that: "functional and scripting languages are more concise than procedural and object-oriented languages; C is hard to beat when it comes to raw speed on large inputs, but performance differences over inputs of moderate size are less pronounced; compiled strongly-typed languages, where more defects can be caught at compile time, are less prone to runtime failures than interpreted or weakly-typed languages."
tyggna writes: "The flame wars of different shells and text editors have long been established, but my question is this: are text editors and various languages linked? Do the majority of Ruby programmers use Emacs? Are most Perl programmers using vim?
Please post your editor and language of choice in the comments."
Please post your editor and language of choice in the comments."
An anonymous reader writes So I, like many people, want to make my own game. Outside of MATLAB, Visual Basic, and LabVIEW I have no real programming experience. I initially started with Ruby, but after doing my homework decided that if I ever wanted to progress to a game that required some power, I would basically need to learn some form of C anyway. Further digging has led me to C#. The other parts of game design and theory I have covered: I have ~8 years of CAD modeling experience including Maya and Blender; I have a semiprofessional sound studio, an idie album on iTunes, and am adept at creating sound effects/music in a wide variety of programs; I'm familiar with the setbacks and frustration involved with game development — I beta tested DotA for 9ish years; I already have my game idea down on paper (RTS), including growth tables, unit types, unit states, story-lines, etc. I've been planning this out for a year or two; I will be doing this on my own time, by myself, and am prepared for it to take a couple years to finish. The reason for listing that stuff out, is that I want people to understand that I know what I'm getting myself in to, and I'm not trying to put out a not-so-subtle "help me make a game for free lol" type of post. With all of that said, where is a good place to start (i.e., recommended books) for learning C# for game programming? I am familiar with object oriented programming, so that's a little bit of help. I'm not necessarily looking for the syntax (that part is just memorization), but more for the methodology involved. If anyone also has any suggestions for other books or information that deal with game development, I would love to hear that too. I know enough to understand that I really don't know anything, but have a good foundation to build on.
An anonymous reader writes "Many years ago, I was a coder—but I went through my computer science major when they were being taught in Lisp and C. These days I work in other areas, but often need to code up quick data processing solutions or interstitial applications. Doing this in C now feels archaic and overly difficult and text-based. Most of the time I now end up doing things in either Unix shell scripting (bash and grep/sed/awk/bc/etc.) or PHP. But these are showing significant age as well. I'm no longer the young hotshot that I once was—I don't think that I could pick up an entire language in a couple of hours with just a cursory reference work—yet I see lots of languages out there now that are much more popular and claim to offer various and sundry benefits I'm not looking to start a new career as a programmer—I already have a career—but I'd like to update my applied coding skills to take advantage of the best that software development now has to offer. (More, below.)
First time accepted submitter ericnishio (3641743) writes "Extending Bootstrap is a concise, step by step manual that introduces some of the best practices on how to customize Twitter Bootstrap for your projects. As the title suggests, you will be learning how to extract the good parts of Bootstrap to create a fully customized package. But be advised: the book is not for beginners." Read below for ericnishio's review.
First time accepted submitter Valejo (689967) writes "According to a study released today by Course Report, programming bootcamps are expected to grow by 2.8x in 2014, meaning that bootcamps will graduate a student for every 8 CS undergraduates. The survey (PDF) also found that 57% of the schools teach in Ruby and that the average tuition is $9,900. The authors collected responses from 95% of US schools, including General Assembly, Dev Bootcamp, and Flatiron School."
DorianGre writes: "I'm working on a new independent project. It involves iPhones and Android phones talking to PHP (Symfony) or Ruby/Rails. Each incoming call will be a data element POST, and I would like to simply write that into the database for later use. I'll need to be able to pull by date or by a number of key fields, as well as do trend reporting over time on the totals of a few fields. I would like to start with a NoSQL solution for scaling, and ideally it would be dead simple if possible. I've been looking at MongoDB, Couchbase, Cassandra/Hadoop and others. What do you recommend? What problems have you run into with the ones you've tried?"
SirLurksAlot writes "News is beginning to circulate on Twitter and various sites that Jim Weirich, the creator of Rake, has passed away at the age of 58. He was an active developer (his last commit in the last 24 hours) and has made many contributions to the Ruby community over the years, as well as being a prolific speaker and teacher. He had a great sense of humor and was beloved by many. He will be greatly missed."
Nw submitter CMULL writes "Stop typing Git over and over again. Ruby on Rails development and consulting firm thoughtbot created an interactive shell dedicated to Git commands, gitsh. One of the primary developers says there is a need for this shell because many early Unix utilities don't take sub-commands like Git."
Today marks the release of Ruby version 2.1.0. A brief list of changes since 2.0.0 has been posted, and file downloads are available. Here are some of the changes:
- Now the default values of keyword arguments can be omitted. Those 'required keyword arguments" need giving explicitly at the call time.
- Added suffixes for integer and float literals: 'r', 'i', and 'ri'.
- def-expr now returns the symbol of its name instead of nil.
- rb_profile_frames() added. Provides low-cost access to the current ruby stack for callstack profiling.
- introduced the generational GC a.k.a RGenGC (PDF).
New submitter John Moses writes "I have been working with node.js a lot lately, and have been discussing with co-workers if node.js is taking steam away from Ruby at all. I think the popularity of the language is an important talking point when selecting a language and framework for a new project. A graph on the release date of gems over time could help determine an answer. The front page of RubyGems only shows data on the most popular, but I am really interested in seeing recent activity. My theory is that if developers' contributions to different gems is slowing down, then so is the popularity of the language."
An anonymous reader writes in with this excerpt from Shirky.com. "The idea that 'failure is not an option' is a fantasy version of how non-engineers should motivate engineers. That sentiment was invented by a screenwriter, riffing on an after-the-fact observation about Apollo 13; no one said it at the time. (If you ever say it, wash your mouth out with soap. If anyone ever says it to you, run.) Even NASA's vaunted moonshot, so often referred to as the best of government innovation, tested with dozens of unmanned missions first, several of which failed outright. Failure is always an option. Engineers work as hard as they do because they understand the risk of failure. And for anything it might have meant in its screenplay version, here that sentiment means the opposite; the unnamed executives were saying 'Addressing the possibility of failure is not an option.' ... Healthcare.gov was unable to complete even a thousand enrollments a day at launch, and for weeks afterwards. As we now know, programmers, stakeholders, and testers all expressed reservations about Healthcare.gov's ability to do what it was supposed to do. Yet no one who understood the problems was able to tell the President. Worse, every senior political figure—every one—who could have bridged the gap between knowledgeable employees and the President decided not to. And so it was that, even on launch day, the President was allowed to make things worse for himself and his signature program by bragging about the already-failing site and inviting people to log in and use something that mostly wouldn't work. Whatever happens to government procurement or hiring (and we should all hope those things get better) a culture that prefers deluding the boss over delivering bad news isn't well equipped to try new things.'"
theodp writes "Nate West has a nice essay on the importance of whimsy in learning to program. "It wasn't until I was writing Ruby that I found learning to program to be fun," recalls West. "What's funny is it really doesn't take much effort to be more enjoyable than the C++ examples from earlier...just getting to write gets.chomp and puts over cout > made all the difference. Ruby examples kept me engaged just long enough that I could find Why's Poignant Guide to Ruby." So, does the future of introductory computer programming books and MOOCs lie in professional, business-like presentations, or does a less-polished production with some genuine goofy enthusiasm help the programming medicine go down?"
An anonymous reader writes "A few months after releasing support for viewing models in .STL format, GitHub just added support for viewing changes to .STL formatted 3D models directly in the browser. 'How does this work? We take both versions of the model, and using binary space partitioning, we compute the added, removed, and unchanged parts. This is done using csgtool, a C library paired with a Ruby gem via FFI. These pieces are cached and displayed by the 3D viewer we already have, though we color them differently and play with their transparency to help illustrate the changes.'"
benrothke writes "Diet books are literally a dime a dozen. They generally benefit only the author, publisher and Amazon, leaving the reader frustrated and bloated. With a failure rate of over 99%, diet books are the epitome of a sucker born every minute. One of the few diet books that can offer change you can believe in is The Healthy Programmer: Get Fit, Feel Better, and Keep Coding. Author Joe Kutner observes that nearly every popular diet fails and the reason is that they are based on the premise of a quick fix without focusing on the long-term core issues. It is inevitable that these diets will fail and the dieters at heart know that. It is simply that they are taking the wrong approach. This book is about the right approach; namely a slow one. With all of the failed diet books, Kutner is one of the few that has gotten it right." Keep reading for the rest of Ben's review.
Kagetsuki writes "While grainy GIF images can have entertaining uses, they aren't the ideal animated image format due to lack of full color support and an alpha channel [for varied transparency]. Animated PNG doesn't have these faults and has been available and incorporated in quite a few browsers since roughly 2004. Lack of tools and recognition has hurt adoption, so to remedy this there is a campaign on Kickstarter to create an Open Source, high quality Animated PNG [APNG] conversion library and GUI Editor based on the APNG Assembler tool 'apngasm.' Even the primary goal includes libraries/modules for C/C++ and Ruby along with a cross platform GUI authoring tool. Aside from supporting the project simply using APNG willl help raise interest and support in the standard and bring us one step closer to a world with cleaner animated images."
Nerval's Lobster writes "Forget about hacking an app or database: for a small cadre of hackers in San Francisco, it's all about writing code that can score them a great table at a hot restaurant. According to the BBC, these developers and programmers have designed bots that scan restaurant Websites for open tables and reserve them. Diogo Mónica, a security engineer with e-commerce firm Square, is one of those programmers. A self-described foodie, he decided to get around his inability to score a table at the ultra-popular State Bird Provisions by writing a script that sent out an email every time the restaurant's reservation page changed. 'Once a reservation got canceled I would get an email and could quickly get it for myself,' he wrote in a blog posting. But soon he noticed something peculiar: 'As soon as reservations became available on the website (at 4am), all the good times were immediately taken and were gone by 4:01am.' He suspected it was automated 'reservation bots at work,' built by other programmers with a hankering for fine cuisine. 'After a while even cancellations started being taken immediately from under me,' he wrote. 'It started being common receiving an email alerting of a change, seeing an available time, and it being gone by the time the website loaded.' His solution was to build his own reservation bot, using Ruby, and post the code in the wild."
Ingy döt Net (yes, that's his name) likes to bridge gaps in the software world. People get religious about their favorite programming languages, he says, but in the end, no matter the language, the methodology or the underlying OS, all programming is about telling computers what to do -- from "add these numbers" to complex text manipulation. Ingy compares a new app or module in the world of Free and Open Source as a gift that the creator has given to others; if that gift can be simultaneously bestowed on users of Perl, Python, and Ruby at the same time, its worth is amplified. So he proposes (and provides a growing set of tools) to make programming language irrelevant, by the sly means of encouraging people to write software using whatever their favorite tools are, but with a leaning toward using only language features which are broadly available to *other* programming languages as well. He's adopted the term Acmeism to describe this approach; Acmeists who follow his lead strive to create software that is broadly re-useable and adaptable, rather than tied only to a single platform.