But hey, I bet if I explained that Word documents are "a major obstacle to the
broader adoption of GNU/Linux", she'd be just fine with it.
It's worth a try. Obviously, you aren't in much of a position to fight about it, but you could ask if you can submit rtf, and point out that Microsoft word can transparently handle rtf files.
You may get yourself in because of your dad, but could you stay there?
Sure. Why not ? Getting in is the hard part. Staying in is relatively easy. And American universities tend
to do a very good job at letting students work at their own very fast or very slow place (if they didn't, it would destroy their football teams)
I work at a university which has a significant number of graduate students who received their undergraduate education from institutions in mainland China.
If your school needs to import a lot of students, how good is the program ?
I am of the opinion that what constitutes a CS education in China is radically different from what constitutes a CS education in North America and Europe.
I am of the opinion that there is probably a lot
of variation in the quality of the institutions
there (as there is in America)
I'm just not yet convinced that this is representative of most cases.
But are you convinced that the applications you receive constitute a representative cross-section of students there ?
C++ is nice for large projects, but its lack of a standard ABI makes dynamically loading modules a little interesting.
Not that interesting. It's about as hard as saying extern "C"
able to inherit from a base class with a bunch of pure virtual functions, and have their implementation be the implementation of the plugin.
But this is quite easy to do. To make this work, you need some variant of the prototype pattern, since you presumably don't know about all the derived classes at compile time. The function that one extracts from a dlopen()ed module should just create register a prototype by inserting it into a static member of the base class (eg: a list or map). To use the prototype pattern, you're going to have to create
and register a prototype regardless, so I don't see how the language is making life more difficult.
Yeah that's easy for you to say, doctor, but what about us stupid people?
When someone is polite enough to use my title, I'm compelled to reply. You don't have to be a rocket scientist to learn vim. It takes a little effort upfront, then some time practising what you've learned, preferably by using it in day to day life.
And fuckin' calculus is too hard too,
Doesn't strike me as hard now, but I remember it being very hard when I was learning it. Learning vim is much easier than learning calc.
Depends. If you're going to write object oriented code, it's a hell of a lot simpler to write it using well documented, standardised semantics than trying to write C++ code in C. In the case of GNOME, complaints about it "adding complexity" are moot -- GTK/GNOME add complexity by using obscure idioms to emulate what C++ supports using well-defined
semantics.
2) No standard ABI (this is a very big point for libraries).
The KDE people have been working on a library that
generates C wrappers for C++ applications.
3) There is a larger pool of skilled C programmers.
If they're really skilled, they shouldn't have much trouble learning C++.
If there were another OO language with a standard ABI, then there might be a case. Maybe Objective C.
Anything but C++, huh ? A standard ABI would be nice, but it's not a be-all-end-all.
I was hoping someone would mention functional programming. I'm developing a system for numeric computation, and one of the difficulties is to create a user-friendly interface in an interpreted language for doing various forms of function composition, and binding. One of the problems is that the users will want to use friendly, dynamically typed interpreted programming languages, but iteration in those languages is slow, and that means that it's necessary to think about things like applying functions to ranges
(or bounding boxes)
While the implementation languages I'm using are non-functional (C++ and python), I'm learning SML/OCaml, and trying to think like a functional programmer.
Not many. I think coders just keep adding useless stuff to these editors because its fun for them,
not because anyone actually needs or uses it.
That's simply not true. The main thing that drives
addition of features to vim is user feedback. Some of the features, like the GUI, multiple buffers (available through GUI) and syntax coloring do not require a lot of expertise to use, they are just there automatically, and they greatly improve the user experience. Other features are more subtle,
such as keyword completion, search/replace, and tags. These features are often used by programmers, experienced developers know about these features, and hence are more likely to look for them in an editor. I'd guess that the vim user base includes a lot of programmers, so features that appear useless to someone writing letters to
grandma are actually very useful to someone writing a long program.
It took me several years to actually learn to use Vi(m).
If it took "several years", you're either a very slow learner, or you weren't putting in much effort.
How many people actually uses Vim and knows more than how to insert characters delete a line or a character here and there and save the miserable output from this horrid piece of software ?
I've written code, and a PhD thesis in vim. Like most people, I know the features that I have the greatest need for. These include visual mode select, jump to matching bracket, keyword completion, jump to line number, recording macros, search/replace, record/play macro, use of multiple buffer windows, and using tags.
I probably aren't using all the features of vim, but I make heavy use of some of the advanced features not available in "classic vi".
I think people will learn what they need to learn.
Serious programmers will probably need a larger
subset of the features than someone who just edits
small files.
I can live with it, mainly because I've had the basic Vi command set memorized longer than most slashdotters have been alive. But I still find it hard to change my mental gears every time I go from Vim to a modeless editor -- even the text box I'm using now. Pressing the ESC key in the wrong context can have nasty consequences!
For truly nasty consequences, try hitting Caps lock instead of (as well as) shift. This has happened to me more than once. Thank god we have multi-level undo!
Why not just store each line in a file named with the line's number and let the filesystem do all that ugly work for you?
Because the editor is designed to work efficiently on all filesystems, on a number of platforms. So it's necessary to write an implementation that works independently of the filesystem. And once it works well on any filesystem, there's not much point in using the system you suggest.
Well, one thing both of you can agree on is that programming is art to the extent that mathematics is art. Suppose I come up with a very elegant proof of a theorem, or a beautiful design pattern (or implementation of one). There is a creative aspect to doing this. I stop short of calling it "art", but it certainly involves a certain amount of creativity, as well as a lot of discipline.
That class alone killed about 40 hours a week, so while you might be able to learn Pascal at your local community college in a year, don't expect to get a world class education like you would at MIT or CMU in 1 year, no matter how many books you've read.
I don't think he's looking for a world class education. I agree with you that there's no easy or fast way to get such a thing.
Have you read a lot of books on probability, set theory and matrix algebra? Have you read any books on modern math? Algorithms (which involved no programming, all proofs)? NFA's and DFA's? Context Free Grammers?
I'm glad that's what you did. I got a PhD in math, and did very similar things (I did a lot of work with finite state automata and group theory), so I feel a little better about not having a CS degree (-;
Yes, people skip the BS and go straight into the masters all the time. For example, a lot of the foreign students studying in America do not have an undergrad CS degree.
CS departments tend to make bridge coursework available -- this is a set of makeup ground work courses for people without CS.
There are a lot of schools that offer make-up bridge courses. If you already know what you're doing, you should have no trouble going straight into a masters program. The truth is that masters propgrams are becomming exactly the kind of 1-2 year diploma that you are looking for, they resemble a kind of graduate diploma more than they do research level graduate study.
You are stuck in a single-dispatch world, without even knowing it, constructing crude approximations of multiple-dispatch with horrors such as x.concat(y).
Actually, the biggest problem with multiple dispatch is that it's simply a complex problem, because you have to worry about tuples of arbitrary subtypes.
Read your Design Patterns book more closely; most of the patterns are probably ways to work around the brokeness and/or inflexibility of the underlying language (C++, even Java/Python).
What you call a "work-around" I call an "idiom". Static typing results in a certain degree of inflexibility, but provides a certain degree of pre-runtime checking. I would say that a lot of the items in GoF give the programmer the flexibility of an interpreted language with static checking.
I'm not sure why you lump python in there btw -- most of the items in GoF are more or less trivial to implement in python.
Now in the object-oriented world, people do not want to be bothered with the problem of reading others code, or thinking for themselves, so they go for these trendy "design patterns" books where other people do the heavy lifting or simply make up garbage to see if it will sell.
This is not true at all. The whole point of studying design patterns is to study someone else's tried-and-true solution to a software design problem. It is not a substitute for forming ones own opinions. It's a tool for forming informed opinions as opposed to spouting ill-founded nonsense like your average slashdotter.
Many many programmers don't get exposed or trained in the way OO. STL code is one way they can get exposed to the possiblities of oo design (though the STL is probably a bit overwhelming and limited).
STL has very little to do with OO design, there is little to nothing in the way of class heirarchy, and
the polymorphism is largely static. STL is for the most part about generic and functional programming. I don't agree that it's "limited",
but it certainly is "a bit overwhelming" (to put it mildly)
I've been using the "patterns" as described in books such as the gang-of-4 one for some years, but I'm not actually happy with the whole thing. Beyond all the hype on patterns, it doesn't seem to deliver the level of reusability and abstraction it is supposed to handle
The problem is that patterns are not really a new thing, they are a way of expressing tried and true software design concepts. Patterns are not going to radically change the world (because they're not a new thing), but having someone bother to write down advanced programming techniques does make it easier for programmers to learn about software design.
Keep in mind that most of the programming that has ever been done predates the study of design patterns
Again, design patterns aren't new, only the terminology is. Most of the programming used design patterns in their various forms, they just weren't called "design patterns".
but obviously it is not a minimum requirement for writing useful code.
But it is. You show me useful code, and I will show you design patterns. C programmers might not have talked about using "the bridge pattern", "the iterator pattern", and "polymorphism", but these patterns are often used, and were understood to be important software design concepts.
Well, I see what you're saying but I think we're going to have a problem discussing this subject if we fuzzy-up the time-frame.
No, you're going to have trouble making your case if we fuzzy up the time frame.
I said that it's hard to determine whether any particular method is a fad or not.
Design patterns are not "a particular method". The
study of design patterns is the study of programming methods that address software design problems. To say that design patterns are "a fad" is to say that software design is a fad. Regardless of what they were called, or what they will be called, design patterns will last as long as people care about software design.
Well, I think the problem is that you have a narrow definition of what a "programming paradigm" is.
So what do you consider to be a programming paradigm ? In fact, name as many as you can.
I'm sure advocates of every methodology for any aspect of computer science believe everyone should rush to study it, but the reality is that there just isn't enough time.
Design patterns is not a methodology, it's the study of methodology for an aspect of computer science (namely, solving software design problems). If you can show me a methodology to solve a certain type of software design problem, I can show you a design pattern. To say that you "don't have enough time" to learn to design software is a copout, and it's inexcusable.
I think your response is a bit harsh. If people have been successfully using algorithms and design patterns without studying them
That's a big if. I'm sure there are a few rare geniuses who can re-invent this sort of thing, and fewer still who refuse to read anything and have such talent, but such people are the exception and not the rule.
In any case, I think the case for studying design patterns is a bit weaker than that for algorithms which has stood the test of time.
Design patterns are not new, the expression "Design patterns" is. Many design patterns have been used for a long time before the "Design patterns" book was written (the "cursor" or "iterator", polymorphism, factories, etc)
Coplien's "Advanced C++ Programming Styles and Idioms" book was written in '91, and this book describes many of the patterns in GoF.
There's so much competition for programmers' attention these days it's hard to tell the latest fad from something of real value.
Solutions to classic programming problems are not "a fad". I believe it's a misconception that design patterns are a "fad", or even that they are "new".
'm sure advocates of every programming paradigm believe everyone should rush to study it, but the reality is that there just isn't enought time.
Again, "Design patterns" is not a programming paradigm. It is more general than that. There are design patterns that relate to functional, procedural, generic, and object oriented programming. Design patterns is about the science of programming, not about the science of programming in a particular style.
Slashdot Mirror
It's worth a try. Obviously, you aren't in much of a position to fight about it, but you could ask if you can submit rtf, and point out that Microsoft word can transparently handle rtf files.
Sure. Why not ? Getting in is the hard part. Staying in is relatively easy. And American universities tend to do a very good job at letting students work at their own very fast or very slow place (if they didn't, it would destroy their football teams)
If your school needs to import a lot of students, how good is the program ?
I am of the opinion that what constitutes a CS education in China is radically different from what constitutes a CS education in North America and Europe.
I am of the opinion that there is probably a lot of variation in the quality of the institutions there (as there is in America)
I'm just not yet convinced that this is representative of most cases.
But are you convinced that the applications you receive constitute a representative cross-section of students there ?
Not that interesting. It's about as hard as saying extern "C"
able to inherit from a base class with a bunch of pure virtual functions, and have their implementation be the implementation of the plugin.
But this is quite easy to do. To make this work, you need some variant of the prototype pattern, since you presumably don't know about all the derived classes at compile time. The function that one extracts from a dlopen()ed module should just create register a prototype by inserting it into a static member of the base class (eg: a list or map). To use the prototype pattern, you're going to have to create and register a prototype regardless, so I don't see how the language is making life more difficult.
When someone is polite enough to use my title, I'm compelled to reply. You don't have to be a rocket scientist to learn vim. It takes a little effort upfront, then some time practising what you've learned, preferably by using it in day to day life.
And fuckin' calculus is too hard too,
Doesn't strike me as hard now, but I remember it being very hard when I was learning it. Learning vim is much easier than learning calc.
That should say "syntax file", it's the spec.vim file.
To be honest, I don't know. I have contributed a spec file to vim, and I might have contributed colors, but that would have been a while ago.
Depends. If you're going to write object oriented code, it's a hell of a lot simpler to write it using well documented, standardised semantics than trying to write C++ code in C. In the case of GNOME, complaints about it "adding complexity" are moot -- GTK/GNOME add complexity by using obscure idioms to emulate what C++ supports using well-defined semantics.
2) No standard ABI (this is a very big point for libraries).
The KDE people have been working on a library that generates C wrappers for C++ applications.
3) There is a larger pool of skilled C programmers.
If they're really skilled, they shouldn't have much trouble learning C++.
If there were another OO language with a standard ABI, then there might be a case. Maybe Objective C.
Anything but C++, huh ? A standard ABI would be nice, but it's not a be-all-end-all.
Using the arrow keys is a terrible habit, and a hard one to kick. I eventually used :map <left> <Nop>, and I'm glad I did.
That's simply not true. The main thing that drives addition of features to vim is user feedback. Some of the features, like the GUI, multiple buffers (available through GUI) and syntax coloring do not require a lot of expertise to use, they are just there automatically, and they greatly improve the user experience. Other features are more subtle, such as keyword completion, search/replace, and tags. These features are often used by programmers, experienced developers know about these features, and hence are more likely to look for them in an editor. I'd guess that the vim user base includes a lot of programmers, so features that appear useless to someone writing letters to grandma are actually very useful to someone writing a long program.
If it took "several years", you're either a very slow learner, or you weren't putting in much effort.
How many people actually uses Vim and knows more than how to insert characters delete a line or a character here and there and save the miserable output from this horrid piece of software ?
I've written code, and a PhD thesis in vim. Like most people, I know the features that I have the greatest need for. These include visual mode select, jump to matching bracket, keyword completion, jump to line number, recording macros, search/replace, record/play macro, use of multiple buffer windows, and using tags. I probably aren't using all the features of vim, but I make heavy use of some of the advanced features not available in "classic vi".
I think people will learn what they need to learn. Serious programmers will probably need a larger subset of the features than someone who just edits small files.
For truly nasty consequences, try hitting Caps lock instead of (as well as) shift. This has happened to me more than once. Thank god we have multi-level undo!
On Putty, you can get by using ^[ for esc (I do this anyway) and ^I for tab.
Cheers,
Because the editor is designed to work efficiently on all filesystems, on a number of platforms. So it's necessary to write an implementation that works independently of the filesystem. And once it works well on any filesystem, there's not much point in using the system you suggest.
I don't think he's looking for a world class education. I agree with you that there's no easy or fast way to get such a thing.
Have you read a lot of books on probability, set theory and matrix algebra? Have you read any books on modern math? Algorithms (which involved no programming, all proofs)? NFA's and DFA's? Context Free Grammers?
I'm glad that's what you did. I got a PhD in math, and did very similar things (I did a lot of work with finite state automata and group theory), so I feel a little better about not having a CS degree (-;
CS departments tend to make bridge coursework available -- this is a set of makeup ground work courses for people without CS.
Actually, the biggest problem with multiple dispatch is that it's simply a complex problem, because you have to worry about tuples of arbitrary subtypes.
Read your Design Patterns book more closely; most of the patterns are probably ways to work around the brokeness and/or inflexibility of the underlying language (C++, even Java/Python).
What you call a "work-around" I call an "idiom". Static typing results in a certain degree of inflexibility, but provides a certain degree of pre-runtime checking. I would say that a lot of the items in GoF give the programmer the flexibility of an interpreted language with static checking.
I'm not sure why you lump python in there btw -- most of the items in GoF are more or less trivial to implement in python.
This is not true at all. The whole point of studying design patterns is to study someone else's tried-and-true solution to a software design problem. It is not a substitute for forming ones own opinions. It's a tool for forming informed opinions as opposed to spouting ill-founded nonsense like your average slashdotter.
STL has very little to do with OO design, there is little to nothing in the way of class heirarchy, and the polymorphism is largely static. STL is for the most part about generic and functional programming. I don't agree that it's "limited", but it certainly is "a bit overwhelming" (to put it mildly)
The problem is that patterns are not really a new thing, they are a way of expressing tried and true software design concepts. Patterns are not going to radically change the world (because they're not a new thing), but having someone bother to write down advanced programming techniques does make it easier for programmers to learn about software design.
Again, design patterns aren't new, only the terminology is. Most of the programming used design patterns in their various forms, they just weren't called "design patterns".
but obviously it is not a minimum requirement for writing useful code.
But it is. You show me useful code, and I will show you design patterns. C programmers might not have talked about using "the bridge pattern", "the iterator pattern", and "polymorphism", but these patterns are often used, and were understood to be important software design concepts.
Well, I see what you're saying but I think we're going to have a problem discussing this subject if we fuzzy-up the time-frame.
No, you're going to have trouble making your case if we fuzzy up the time frame.
I said that it's hard to determine whether any particular method is a fad or not.
Design patterns are not "a particular method". The study of design patterns is the study of programming methods that address software design problems. To say that design patterns are "a fad" is to say that software design is a fad. Regardless of what they were called, or what they will be called, design patterns will last as long as people care about software design.
Well, I think the problem is that you have a narrow definition of what a "programming paradigm" is.
So what do you consider to be a programming paradigm ? In fact, name as many as you can.
I'm sure advocates of every methodology for any aspect of computer science believe everyone should rush to study it, but the reality is that there just isn't enough time.
Design patterns is not a methodology, it's the study of methodology for an aspect of computer science (namely, solving software design problems). If you can show me a methodology to solve a certain type of software design problem, I can show you a design pattern. To say that you "don't have enough time" to learn to design software is a copout, and it's inexcusable.
That's a big if. I'm sure there are a few rare geniuses who can re-invent this sort of thing, and fewer still who refuse to read anything and have such talent, but such people are the exception and not the rule.
In any case, I think the case for studying design patterns is a bit weaker than that for algorithms which has stood the test of time.
Design patterns are not new, the expression "Design patterns" is. Many design patterns have been used for a long time before the "Design patterns" book was written (the "cursor" or "iterator", polymorphism, factories, etc) Coplien's "Advanced C++ Programming Styles and Idioms" book was written in '91, and this book describes many of the patterns in GoF.
There's so much competition for programmers' attention these days it's hard to tell the latest fad from something of real value.
Solutions to classic programming problems are not "a fad". I believe it's a misconception that design patterns are a "fad", or even that they are "new".
'm sure advocates of every programming paradigm believe everyone should rush to study it, but the reality is that there just isn't enought time.
Again, "Design patterns" is not a programming paradigm. It is more general than that. There are design patterns that relate to functional, procedural, generic, and object oriented programming. Design patterns is about the science of programming, not about the science of programming in a particular style.