Something For (Almost) Every Developer 263
First up, reader martinjlogan sends along a tutorial for setting up a workable Erlang/OTP development environment on a Mac. Next, reader acid06 notes news of Perl 5.12, including what may be the first delivered fix for the Y2K38 bug. (Hit the Read More link below for some details on Perl's new release strategy.) "After two years of development, the new major version of Perl is now available. Notable new features are: better Unicode support, proper support for time after the Y2038 barrier, new APIs to allow developers to extend Perl with 'pluggable' keywords and syntax, warnings for deprecated features and more. From the linked post: You can get it from the CPAN right now or wait for a platform-specific release (such as Strawberry Perl for Windows)." Finally, from reader snydeq: "InfoWorld's Martin Heller provides an in-depth review of Visual Studio 2010 and finds Microsoft taking several large steps away from its legacy IDE code. 'Visual Studio 2010 is a major upgrade in functionality and capability from its predecessor. Developers, architects, and testers will all find areas where the new version makes their jobs easier. Despite the higher pricing for this version, most serious Microsoft-oriented shops will upgrade to Visual Studio 2010 and never look back,' Heller writes. Chief among the improvements are Microsoft's revamping the core editing and designer views to use WPF, its overhaul of IntelliSense and support for test-driven development, and its intelligent support for multiple versions of the .Net Framework."
Re: Perl. This release cycle marks a change to a time-based release process. Beginning with version 5.11.0, we make a new development release of Perl available on the 20th of each month. Each spring, we will release a new stable version of Perl. One month later, we will make a minor update to deal with any issues discovered after the initial ".0" release. Future releases in the stable series will follow quarterly. In contrast to releases of Perl, maintenance releases will contain fixes for issues discovered after the .0 release, but will not include new features or behavior.
VS upgrade cycle (Score:5, Insightful)
most serious Microsoft-oriented shops will upgrade to Visual Studio 2010 and never look back
Of course, implying that you're not a serious Microsoft-oriented shop if you don't upgrade. This is the exact opposite of the case. As Microsoft regularly changes stuff in VS that no-one wants, most people don't upgrade until necessity forces it on them. It's entirely network effects. If you're using precompiled third party libraries and they upgrade, chances are you'll be forced to upgrade. If Microsoft made it easier to use the new IDE without upgrading the compilers, the standard lib, the header install, etc, I imagine more people would accept the feature improvements (and the bug fixes!) to the IDE without trepidation.
Stereotyping? (Score:2, Insightful)
Re:VS upgrade cycle (Score:1, Insightful)
He was implying no such thing.
Most serious Microsoft-oriented shops will do X =/=> All shops who do not do X are not both serious and Microsoft-oriented.
most people don't upgrade until necessity forces it on them
Not my experience when it comes to Visual Studio.
If Microsoft made it easier to use the new IDE without upgrading the compilers, the standard lib, the header install, etc, I imagine more people would accept the feature improvements (and the bug fixes!) to the IDE without trepidation.
Bad, bad, bad, bad, bad idea.
So... (Score:5, Insightful)
We've started churning out pointless stories all day and then cramming four actual news posts into a single thread?
Re:VS upgrade cycle (Score:5, Insightful)
Bad, bad, bad, bad, bad idea.
I think its a great idea.. there's no reason why the IDE release cycle has to be tied to the compiler release cycle.. except that Microsoft likes the lockin.
2K38? (Score:5, Insightful)
Would it hurt to just write 2038? No space is saved writing it the other way.
Re:VS upgrade cycle (Score:3, Insightful)
They can have my MSVC 6 when they pry it from my cold dead GLURK, gaaasssspp...
One problem I've had is the new redistributable requirements of each release. Not insurmountable, but a real concern when considering an upgrade.
Re:VS upgrade cycle (Score:3, Insightful)
CPAN installs everything you need, that is why the tool cpan exists. If it takes extra work, you are doing it wrong.
1. if it does not do what you want, don't use it
2. just fix the code like you would fix your own, or replace it.
3. if you don't have source don't use it. No blackboxes that way.
4. So long as code is all internal who cares.
5. Use the features you need.
6. Again if you don't have source you are a fool to use it.
7. No, this is wrong. This is why every damn windows apps brings along it's own copy of everything. Get a fucking package manager you dolts.
8. same issue when you have more than 1 developer internal or external.
wtf? (Score:5, Insightful)
Awesome. From now on, let's just post 1 story on Slashdot per day with all of the good stuff in it, so that we may discuss everything in it in one big unrelated clusterfsck of comments.
Re:VS upgrade cycle (Score:4, Insightful)
there's no reason why the IDE release cycle has to be tied to the compiler release cycle..
There's Intellisense which, you may have heard, is kind of a big deal about Visual Studio. If the language adds new constructs (which is does), and the IDE isn't updated to cope with that, then you end up with useless, or even worse-than-useless, Intellisense.
What they could do is have the language team produce and release a patch for Intellisense to correspond to their language releases, but then you get into the nasty situation where the language team has to build and QA patches for 3 or 4 versions of Visual Studio-- bugs would creep in, undoubtedly.
Re:So... (Score:3, Insightful)
At the very least, it could have been 4 actual entries so that the comments don't just become a huge clusterfuck.
But... nobody running Slashdot gives a fuck. They don't even pretend, really.
Re: new major version of Perl is now available. (Score:5, Insightful)
It's considered trolling because that's purely what it is.
Perhaps you'd like to enlighten us with some examples of "byzantine syntax", since Greek and Latin [wikipedia.org] aren't valid Perl. Perhaps you meant "British" syntax, since the language is based more off of English than other programming languages. Yes, I'm aware this places it in the same group as COBOL, but hear me out.
Perl's syntax is based off natural language. You should be able to tell the computer what to do in the same way you'd tell another person, with some obvious extra clarity needed. In this regard, it is the opposite of INTERCAL. In Perl, when you want to run a function 'foo' if and only if 'bar' is true, the statement is very close to what I've just said.
foo if bar;
Sure, it's not like C, but why should we limit our thinking? Alternatively, just as in English you can say "If 'bar' is true, run 'foo'":
if (bar) { foo }
Perl is a language for people who use language. Even the more ugly syntax makes perfect sense with a bit of thought:
s/foo/bar/g;
That's a full statement, saying "substitute foo with bar globally". It applies to whatever you happen to be working on at the moment, just like how there are many statements in English that carry an implied 'you'.
The syntax of the Perl language is only ugly if you try to forget that it is a language. Perhaps other languages should try to emulate Perl's features, and actually gain some readability. Sometimes, it just makes more sense to express things differently. Would COBOL be so bad if it allowed BASIC's syntax as well (and allowing non-computer people to write in it carried the death penalty)?
Re: new major version of Perl is now available. (Score:1, Insightful)
Things that suck: the implicit variables and default pattern space, the special variables with a sigil and another punctuation character, the fact that there are sigils and subroutines without named parameters, the irritating hassle that is hashes of hashes, the ugly shitball bolted on OO support. Nor is CPAN is a plus, with the thousands of modules that partially and/or totally duplicate one another's functionality or that fail to work owing to years of neglect or, more often, carelessness of packaging on the programmer's part.
But the worst part about perl is the ethic of TMTOWTDI. In practice means either that one finds it done a new way for every 1000 or so lines, or that someone's imposed exactly their way to do it. Your programming is not art, and you are not writing literature; you are not a code poet. Expressing yourself in code is nowhere nearly as important as writing something stable and maintainable. One - just one - good, obvious way to do it; something that's predictable and that works. Something that, when you've moved along, the next guy can look at and not have to ask aloud what fucking asshole did this.
There's better choices out there now, even among scripting languages. We don't need to keep using the monstrous bastard amalgam of sh, sed, awk and Larry Wall's pretenses of being a linguist. Learn some new skills, and let's all just let the fucking thing die already.
Re:VS upgrade cycle (Score:2, Insightful)
What do you mean by backwards compatibility?
Lets say they allow you to open up solutions file unchanged from VS2005. When ever you load a VS2005 solution, any new VS2008 feature that has some aspect of it saved in the solution file would have to be disabled. That also means additional code paths all over the place checking if you have a VS2005 solution loaded up or a VS2008 solution loaded up, and the displaying of appropriate error messages whenever the user tries to use such a disabled feature.
That is a messy solution, especially given that the most common imagined scenario is for a team of programers working together to all be using the same version of Visual Studio.
For a product like Word it may be worth it to extend the extra engineering effort to enable backwards compatibility for years on end (IIRC Office 2000 files can interoperate with Office XP and 2003 files A-OK, so two major releases), but for a product used by technical users, one expects that the technical users would rather have other aspects of the product polished more (gated checkins! Holy cripes, TFS finally has gated checkins!) and for developers to just run a one time wizard and convert their project over.
And actually it is possible to maintain a project across both VS2005 and VS2008. If you need a project to be used by both versions of VS, you only have to bother when changing project references or adding new source files, open the appropriate solution file up in both versions of VS and make the change to the project or the solution.
Yes it sucks. I've hit this same issue when VS2008 first came out and not everyone on my team was using it, yes it is a PITA. The solution was to tell everyone that they had to just get around to installing VS2008 before the next time they pulled down the latest copy of the code.
(And yah I see how it could suck if you have multiple teams and some team wants to stay with VS2005 for whatever reason)
But really, VS2008 supported so many new types of solutions, and in some cases, completely brand new ways to have certain types of solutions organized, that the file format was going to change. Just thinking about it for 10 seconds or so and it seems like maintaining back compat would have involved a UI nightmare, telling users seemingly random features are disabled always sucks, and should be avoided whenever possible.
Re: new major version of Perl is now available. (Score:2, Insightful)
Well, there is Lingua::Romana::Perligata. Predictably, we have Damian to blame for that.