Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment Learning new mindsets (Score 4, Insightful) 267 267

Over the years, I've worked with about 20 different languages. I learned a lot of them purely out of interest. Even if you won't need it for any "serious" or paying work, it can be useful to learn a new language that is different from the languages you know. For example, if you know C# you won't learn that much by working with Java; they're too similar. By contrast, if you try learning a language like Haskell or Go instead you'll get introduced to new ways of thinking.

In almost all languages, there are things you can do easily or "naturally" in it. These language (and framework) features usually influence how you would design a program in that language. And it's these concepts that are worth learning. For example, when I learned Ruby and later Haskell, I learned how powerful concepts like map/select or working with closures are.

This knowledge then transferred to the languages I usually work with; my designs in my "traditional" languages changed because of the things I learned while working with other languages.

So even if the new language is not "one the rise" it might pay off by indirectly improving your skills in the languages that you do get paid for.

Comment Re:Use GIT (Score 1) 343 343

Dang, me using the incorrect case of the "v" suddenly destroyed several years of experience? Oh gosh, and I thought actually following the mailing-list for several years since the betas and reading about how and why those people designed the tool would give me some understanding about it, but you're right: spelling is way more important.

Comment Re:Use GIT (Score 3, Interesting) 343 343

I've worked on a SubVersion project for several years where the smallest useful checkout was 5GB (it was an in-house Linux distribution I've built and maintained). On a local network, SubVersion works pretty well for these things but you're right, I wouldn't want to do this over a poor Internet connection. It's pretty space efficient with binary files and handles things like copies and renames very well, so if you need to deal with them a lot then SubVersion is a good choice. Git and SubVersion work very differently, each have features the other doesn't have, by design. Believe it or not, SubVersion was also *designed* for large projects, but different use-cases. I really, really wouldn't want to maintain my distribution with Git. Now that I'm a "normal" developer again, we're using Mercurial and Git since they're better suited for these tasks, handling source/text files with lots of branching and merging.

Comment Re: Use GIT (Score 1) 343 343

Have you ever split a large project into several components stored in different repositories and tried to keep them in a consistent state? Like, trying to rebuild a version exactly as it was one year ago because a customer needs a very specific fix for that version? I've come to learn that especially with huge projects it can be a very good idea to have everything in one repository.

Comment Re:DO NOT Use GIT (Score 4, Interesting) 343 343

With SubVersion, you can check out subtrees instead of the whole repository (even non-recursively, so you can check out a directory "in the middle"). That's something that Git or Mercurial can't do by design; IIRC it's because the always-complete-repository approach makes merging and other tasks much, much easier. In your SVN working copy, only the data of commit you've checked out are stored. For everything else SVN needs to contact the server which depending on the requirements and workflow, is either a good or bad thing. On the other hand, Git and Mercurial do have the complete history locally which allows them to perform a lot of tasks without contacting a server that SubVersion could not do (simple example: get log history of a file).

But it's actually besides the point: all of these things won't matter to an office user. Ease-of-use and chances-to-screw-up do.

Comment Re:Use GIT (Score 5, Interesting) 343 343

Now you've got into rant-mode, sorry. I really hope non-technical people are never forced to actually type in commands but use a GUI instead, no matter which VCS they use. But especially with Git. I think Git is a very powerful tool and have come to like it for its features, but I still hate it for its commands and what I feel are inconsistencies and "fuck how other VCS are naming it, we use something different".

For example, discard changes on a single file: "git reset foo.bar". Discard changes on all files: "git checkout -- .". WTF? Just a few days ago, I wanted Git to give me the diff of specific commit, the equivalent to "svn diff -c revision" or "hg diff -c revision". In git? "git diff revision^ revision" or "git diff revision^!" (which I overread when I was reading the man page and needed to look it up on Ye Olde Interweb). Or "git diff-tree -p revision" or "git whatchanged -m -n 1 -p revision" since why not? And "git add" both adds a new file to the repository but also picks a modified file to be included in the next commit (but only the parts that have not changed between add and commit. The add behaviour does make sense when you think "from the inside" of the VCS, but I was confused at first and I'm a technical guy. Normal people will have trouble with this stuff. Seriously, I've been using various VCS in last two decades and still am doing a lot in the shell, especially VCS stuff since I feel to be more in control this way. But Git is the first VCS that I use almost exclusively in a GUI because it's CLI is too cumbersome.

Comment Re:Use GIT (Score 4, Informative) 343 343

I've been using SubVersion since it was in beta and have used it at work and in private in multi-gigabyte projects. SubVersion was always rock-solid for us, and it's handling binary files very well (which was the prime reason we decided to switch use SVN back then in about 2003). Git is an excellent tool for us developers, but I feel it's way too complicated for non-technical people who don't need these bells and whistles.

Comment Re:BASIC (Score 1) 185 185

That's exactly how I started as well. The manuals I had were in english (plus DOS; that's how I picked up basic english) but we had books in our library that were in German. So not knowing english doesn't stop you, but I guess it would've been easier/nicer if I would've been able to start in my native tongue.

Comment Re:Priorities (Score 2) 185 185

Why not use the time to learn English first. It will be more useful to her than programming.

Learning a whole language first isn't much fun. Also, lots of people I know (me included) learned programming first, then (through programming) english. I started with GW-BASIC at age of 7 and almost everything was in english: the programs I had, even the manuals. I picked up basic english from this (after some trial and error you understand what certain words or phrases mean; I was pretty surprised when I learned at school that these words are pronounced totally differently than I imagined ;-)

I even knew a pretty good programmer who still does not speak english. He couldn't ask for directions if he'd get lost. Yet he manages to do hold up as a professional. Couldn't believe it at first, but it shows that knowing english does help when developing but it's not strictly necessary. The good thing about programming is that the syntax rules are so much more strict and easier to understand than natural language.

Comment Re:Stop (Score 4, Insightful) 185 185

This is encouraging, not forcing. So I'm all for it. If a friend of my father hadn't introduced me to programming at age of 7, I would have missed something that soon turned into a passion and is now my day job. That was the most important event in my life, second only to my birth. You have to give kids the chance to try something to see whether they like it, like chemistry or electronic kits. If they like it, great! If not, so what.
Data Storage

ZFS Hits an Important Milestone, Version 0.6.1 Released 99 99

sfcrazy writes "ZFS on Linux has reached what Brian Behlendorf calls an important milestone with the official 0.6.1 release. Version 0.6.1 not only brings the usual bug fixes but also introduces a new property called 'snapdev.' Brian explains, 'The snapdev property was introduced to control the visibility of zvol snapshot devices and may be set to either visible or hidden. When set to hidden, which is the default, zvol snapshot devices will not be created under /dev/. To gain access to these devices the property must be set to visible. This behavior is analogous to the existing snapdir property.'"

If money can't buy happiness, I guess you'll just have to rent it.

Working...