[Haifux] [W2L] Call for lecturer + "Linux guru"

Sun Oct 18 20:27:21 MSD 2009

On Sunday 18 Oct 2009 11:49:36 boazg wrote:
> i don't think 20 minutes is enough for subversion if students are to use
> svn+ssh:// from t2. an hour is minimum. it should get it's own seperate
> lecture, IMHO. also, it shoudl be pitched seperately, as it has apeal also
> for students working on obscure OS's that arent POSIX-like. just another
> hook for FOSS.

‏Yes. Indeed, one of Subversion's main selling points is that it works fine on 
Microsoft Windows's Win32 (without the need for cygwin or any other funky 
stuff - though it works fine in cygwin too.). I recall a few years ago that a 
few Subversion developers worked on a Subversion port to IBM EBCDIC-based 
platforms, which don't even have ASCII and UTF-8, because there's some demand 
for it. Don't know how well Subversion runs on VMS, VxWorks, Windows CE, and 
other "weird" not-entirely-Unix OSes. 

> git, imho, for your averige MATAM student, would take much longer than that
> to learn, to the point where it's useful. once you understand SVN and have
> some experance, it's much simpler to learn git later down the line.
> 

You are right on the mark here. I think subversion (or possibly also hg) is a 
useful stepping stone to git, similar to the fact that I always recommend 
beginning programmers to start learning Perl/Python/Ruby/etc. before they 
learn C, because I knew that it really helped me to know GW-BASIC/QBasic/etc. 
before I learnt C, [BASIC] because by learning BASIC, I had a grasp on some of 
the basic (pardon the pun) elements of programming. And yes, I learned C, 
C/C++, as well as Perl, UNIX/Linux, some Win32 and MFC programming and bits of 
other stuff before I came to the Technion, and would recommend anyone to do so 
as early as possible.

Regards,

	Shlomi Fish

[BASIC] - yes, I got it - I'm mutilated for life. Please stop parroting and 
misapplying Dijkstra's opinions from the 60's or earlier. Some old dogs cannot 
be taught new tricks. But all people are capable of growing with the right 
attitude and overcoming their old limitations (elephant tied to a rope in the 
circus and all as opposed to a human being and all). I hate fatalism with a 
passion.

> On Sun, Oct 18, 2009 at 08:51, Ohad Lutzky <ohad at lutzky.net> wrote:
> > In the case that this is only a 20 minute lecture, I wholeheartedly
> > agree. I do think that git should be mentioned, in a one-liner, as "a
> > more advanced tool that also allows you to work offline".
> >
> > So, while I agree that git is too complicated to learn in 20 minutes
> > (takes 1-2 hours from my experience), it has a different upside when
> > compared to subversion: Administration is far easier. This is true for
> > any DVCVS, and stems from the fact that nobody needs write-access to
> > anything but his own files. Users will want to use whatever VCS is taught
> > in order to collaborate, and this requires some support work from the
> > admins, which should be taken into account. Either that or an alternative
> > free, easy-to-setup, fast and technion-accessible solution should be
> > shown.
> >
> > On Sun, Oct 18, 2009 at 8:37 AM, Shachar Shemesh 
<shachar at shemesh.biz>wrote:
> >>  Ohad Lutzky wrote:
> >>
> >> Of course it would. But this one puts a lot of candy down that same path
> >> as well. These mines hurt, but are not fatal (again, from my experience,
> >> all mistakes can be recovered if detected within a reasonable time), and
> >> git's features make it, IMO, worth the trouble. For example, while many
> >> people find the staging area confusing (you have to "add" a file you've
> >> changed again in order to commit it, or just use commit -a to
> >> automatically add all changed files), it allows git to do awesome stuff
> >> like "git add -p"; this command goes over the differences from the
> >> previous version (like git diff), and asks you which hunks to stage.
> >> This means you can make a set of changes, realize it can be logically
> >> split into two, smaller sets of changes, and proceed to commit it as two
> >> sets of changes. Or, for a more common case, it allows you to stage only
> >> your actual fix to the commit without the various debugging statements
> >> you've added across your code in order to track down a bug, and do a
> >> quick "git reset --hard" afterwards.
> >>  There's a succinct list of reasons I like git here:
> >> http://whygitisbetterthanx.com/
> >>
> >>   I'm getting the sense that this conversation has gone off the main
> >> track a little. This is, I'll admit, also my fault. The question here is
> >> not "which VCS is better" (for which my answer, if you look at it, is
> >> "depends"), but "which VCS should we teach in the dev lecture of the W2L
> >> series".
> >>
> >> Here's the thing. When you first start to use a new system, what you see
> >> is mostly the mines. If this is the first system of its kind, you are
> >> likely to run into mines that are not really mines, but your
> >> misunderstanding of what the system is supposed to do, but still, the
> >> mines (real and conceptual) are mostly what you see. You do not,
> >> typically, see the candies, for the very simple reason that you do not
> >> understand the system well enough to appreciate or make use of them.
> >>
> >> As you use of the system matures, you learn to change your thinking to
> >> not regard some things as mines, and avoid the real ones. As that
> >> happens, the mines become less and less important, and the candies
> >> become more and more interesting. The main pre-requisite for that
> >> happening is that YOU HAVE NOT GIVEN UP ON THE TOOL!
> >>
> >> This thread started around a very specific question - should Haifux
> >> teach git, or some other version control system, as part of the
> >> development tools lecture. Any answer should take into account that
> >> amount of time given for this part of the lecture (between 10 and 20
> >> minutes), and the amount of tutoring the students will have down the
> >> road (none unless they seek it). Under those conditions, in my opinion,
> >> git is the wrong tool because:
> >>
> >>    - Anyone who has any experience with VCS will, likely, have used
> >>    server based ones. Git, for them, contains all of the misconception
> >> mines that go with a distributed revision control
> >>    - Git has some actual bone-fide mines, lain on the path traversed
> >> even by relatively basic VCS operations.
> >>    - None of the candies matter, as you only have 20 minutes (best case)
> >>    to show them the tool and set them on their way, and the candies
> >> require the user to "get" version control in order to be appreciated.
> >>
> >> With the amount of time you have, you will be lucky to get 20% to
> >> appreciate the fact they can restore any version they checked in in the
> >> past. Showing them git because it can split a single change into
> >> multiple commits will fly so far over their heads, I'm afraid none of
> >> them will even run a single git command to even check out the water.
> >>
> >> Shachar
> >>
> >> --
> >> Shachar Shemesh
> >> Lingnu Open Source Consulting Ltd.http://www.lingnu.com
> >
> > --
> > Man is the only animal that laughs and weeps, for he is the only animal
> > that is struck with the difference between what things are and what they
> > ought to be.
> > - William Hazlitt
> >
> > Ohad Lutzky
> >
> > _______________________________________________
> > Haifux mailing list
> > Haifux at haifux.org
> > http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
> 

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Best Introductory Programming Language - http://shlom.in/intro-lang

Chuck Norris read the entire English Wikipedia in 24 hours. Twice.