Slashdot Mirror
Something For (Almost) Every Developer
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.
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.
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.
How we know is more important than what we know.
So almost every developer either: a) Uses Erlang and a Mac b) Uses Perl or c) Uses VS2010? Is it just me, it would there still be a fair chunk of developers not included?
We've started churning out pointless stories all day and then cramming four actual news posts into a single thread?
Would it hurt to just write 2038? No space is saved writing it the other way.
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.
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 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)?
You do not have a moral or legal right to do absolutely anything you want.
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.
> since Greek and Latin aren't valid Perl
Well, there is Lingua::Romana::Perligata. Predictably, we have Damian to blame for that.
Cut that out, or I will ship you to Norilsk in a box.