T
thufir
The minor copying of an idea from ruby isn't bloat, though.
-Thufir
The minor copying of an idea from ruby isn't bloat, though.
-Thufir
A
Andreas Leitgeb
rotfl. 'nuff said. ur 0wnd
A
Arved Sandstrom
thufir said:
Like Lew I learned FORTRAN (FORTRAN 77) in university, along with VAX
Assembler. The only real benefit of university in learning those languages
was that I myself could not afford to lease and operate either a CDC 6400 or
a VAX 11/780 at home. Every language I have learned since I have learned
myself.
I don't rule out the usefulness of a good (I stress this word) course in a
first programming language. It obviously can't hurt to learn the
fundamentals of good programming from a good teacher. But there's no good
reason why subsequent programming languages can't be self-taught. I have in
fact used FORTRAN for real, but most every language I've used in the past
three decades I had to pick up on my own.
In addition, a good CS curriculum will cover(among other things) algorithms
and data structures in depth, something that is not usually emphasized in
standalone programming courses, and also not something that teach-yourself
programmers tend to study. And ideally in a good CS program you'll also get
taught software engineering, again not something that a standalone
programming language course will emphasize, and again not something that
do-it-yourself programmers usually see as a major goal. But this presupposes
a *good* CS program.
I myself realized well into my career that my imperfect understanding of
algorithms and data structures was hurting me, so I bought Knuth (The Art of
Programming) and Sedgewick (Algorithms in C) and proceeded to brush up.
Similarly, and also well into my career, I decided that some formal
knowledge of software engineering was in order, so on my own time I took a
certificate from DalTech in software engineering, covering software project
management, QA and testing, requirements analysis, design, maintenance, and
some other odds & ends. The latter was the first and only formal education
in the field I've had since leaving school.
Some other things to keep in mind about learning programming languages
through courses. Unless offered in sequence as part of a structured
curriculum, they usually have to start off with the assumption that for some
students it's a first language. Hence the treatment will be basic, and taper
off at a dissatisfying intermediate level at best.
Also, why assume that the teacher is an expert on the language? Not
infrequently the instructor's qualifications are simply (a) that they
learned the language/technology before you did, and (b) they know just
enough about it to teach the *course*. When a new programming language comes
out, there's no finishing school that prospective instructors attend - they
learn it the same way that any other developer does, by teaching themselves.
They may not even have had to seriously use it before they end up teaching
it. As an example, a former colleague of mine at one job was a part time CS
instructor at a local university. He was a real wizard at C++ and a pretty
good programmer.But he was just in the process of teaching himself Java when
he got tapped to teach a course in it...he was literally learning Java
concepts just in time to teach them. Take my word for it, his students were
not well-served when it came to some aspects like concurrency.
Bear in mind too that programming language courses don't always show up when
you need them. They tend to get offered when there's already a solid base of
people who (somewhat) know technology X, and there has been enough hype
about X so that some of that first group decides to teach courses in X. For
a developer that's frequently too late. In my area (Nova Scotia) the first
courses in XML didn't start showing up until well after 2000, and there are
many other examples.
So in the final analysis you'll do just as well or better if you teach
yourself, provided that you have a solid grasp of fundamentals, and you know
how to learn. Just learning how to run code snippets and modify them a bit
won't cut it, obviously.
Incidentally I am just teaching myself Ruby. Main motivation being, I have
some reasonable expectation that I might use RoR on some project in the near
future. Having determined on both Windows and Linux that you can develop
something of a working web app using Rails without knowing any Ruby at all,
I turned to the fundamentals and am using "Programming Ruby", and setting as
my goal real-world small programs that I already know how to write in a
number of other languages. The primary target here is to learn the Ruby
idioms...what's the Ruby way of doing things? But one thing's for sure - I'd
absolutely be wasting my time paying for a course in Ruby. I can learn more
in a week of my own free time than I would in a month's worth of evening
classes at some campus.
AHS
A
Arne Vajhøj
Arved said:
+1
Arne
T
thufir
It's a standard, though. What's the downside?
-Thufir
T
thufir
So far, BCIT has been a disappointment on this front. Of course, I
should be doing my homework, which is on data-structures, rather than
browsing usenet!
-Thufir
A
Arved Sandstrom
Stefan said:
Of course, by the blogger's own admission he wasn't exactly a technical
type. Depending on the question it wouldn't be so tough to answer it in a
minute or less...think of the wizardry you can do with UNIX shell.
Not so long ago it wasn't all that common to find Windows types who knew any
awk or Perl or Tcl or Python or Ruby. On that same note, how many Windows
users *now* use PowerShell? Every job I've had there have been the odd
assortment of little administrative and system tasks come up that lent
themselves ideally to a shell script or scripting language program, nothing
super complex, and I'd apply myself for a half hour or hour to produce a
useful tool. This productivity is mystifying to coders who know only Java
or C++...let alone non-technical types.
Every place I've worked I've known at least a few superfast typists. Not
infrequently they were also the people who knew every keyboard shortcut
under the sun (arguably good to know for easing the stress on fingers and
forearms). So they were able to execute a number of administrative tasks
considerably faster than me. But in the big scheme of things this barely
mattered.
AHS
T
thufir
Making getter and setter methods annotations (or the option to use
annotations instead) wouldn't, to my view, bloat Java. I don't see the
downside.
-Thufir
S
Stefan Ram
Arved Sandstrom said:
Ron Garret was a researcher for NASA's Jet Propulsion Lab
before he joined Google in June 2000 as employee No. 104.
In 2000, he also wrote papers such as
»Lisp as an Alternative to Java«
http://www.flownet.com/gat/papers/lisp-java.pdf
(His name was »Erann Gat« then.)
A
Arved Sandstrom
Stefan Ram said:
Hmmmm. Yeah, I missed that - looked at the "About Me" section...Doug Edwards
being decidedly non-technical.
Still, I did read the comment by Ron. Not carefully enough the first time
around, so after second read I'll acknowledge that by most definitions he's
a technical type. I sympathize with the guy - it's not that hard to end up
in a job that you're ill-suited for. Back in the early and mid-90's I did
primarily scientific programming myself (FORTRAN, awk/nawk/gawk, shell,
C/C++, Perl, Matlab) on VAX and UNIX, and it was quite a transition to
business-land and Web apps...I might have been in as much of a lurch as this
guy if I'd started out with the wrong company.
AHS
T
Tris Orendorff
thufir said:
The downside is that a 1:1 mapping of variables to get/set methods exposes your implementation as much as making all those variables public. That being said, I don't think your annotation idea would bloat Java either.
P
Patricia Shanahan
Tris said:
Providing get/set methods for a variable does not expose the
implementation as much as making it public. Of course, it is only a good
idea if the variable represents some attribute that should be the
subject of get/set from outside the class.
In that case, making the variable public creates a commitment to
continue to represent the attribute as a variable. Providing get/set
methods only commits to the attribute continuing to exist. It may be
represented some other way in the future without affecting code outside
the class.
Patricia
S
Stefan Ram
Patricia Shanahan said:
This mixes two views: The interface and the implementation.
From the implementation view, there might be getters and
setters for variables, but from the interface view, there
are only operations with behavior - no variables. So, one
can not refer to variables in the interface documentation,
the best approximation would be to say that some operation
behaves /as if/ the object would have a variable and the
operation would return its value.
Information hiding can be preserved better if request or
report methods are used instead of setters. So instead of:
/* Sets the color of the object to BLUE. */
object.setColor( BLUE );
one can use
/* Report to the object that the clients preferred
object color now is BLUE. */
object.reportColorPreference( BLUE );
In the second case, we do not refer to a property, but
report out own preferences. The object then /should/ fulfill
the clients wish if possible. The implementation might be
the same as for »setColor«, but the documentation of the
interface more closely reflects that the client does not
have direct write access (because the object might deny
the operation).
Instead of getters, on can tell the object what to do.
»Tell, don't ask.«
/* Gets the color to print it. */
print( object.getColor() );
/* Tell the object to print the color. */
object.withColorDo
( new VoidMethod<Color>(){ public void m( final Color c ){ print( c ); }});
Which, of course would be simplier to write if Java had
literals for parameterized block objects like Smalltalk.
T
Thufir
Oh, a previous persons suggestion (I think this sounds right, but
pardon the syntax):
@getters: foo, bar
@setters: baz
@gettersAndSetters: foobar
so there would be flexibility, and if you didn't want something
exposed just don't list it.
-Thufir
P
Patricia Shanahan
Thufir wrote:
....
How about public vs. default visibility? I have had a situation in which
I wanted classes in the same package to be able to both set and get, but
classes outside the package to only be able to get.
How would you insert logging, or set debug breakpoints, in
auto-generated methods?
Patricia
....
How about public vs. default visibility? I have had a situation in which
I wanted classes in the same package to be able to both set and get, but
classes outside the package to only be able to get.
How would you insert logging, or set debug breakpoints, in
auto-generated methods?
Patricia
A
Arne Vajhøj
Patricia said:
Not that I am particular positive about the idea, but if it were
to be implemented, then I would expect the automatic stuff to
have default behavior (public access, single assignment/return etc.)
but be overridable by a programmer implementation.
Arne
E
EricF
I was about to respond with something very similar to Arne's comment.
If you are interested in this sort of thing, take a look at Groovy and
Groovy Beans. Groovy runs in the JVM.
http://groovy.codehaus.org/Groovy+Beans
Eric
M
Mark Space
Arne said:
Sure, or over-ridable with a different annotation, or by just plain
doing it yourself:
public class Example {
@PublicGetter
private int value;
@PackageGetter
private int packageValue;
private int protectedValue;
protected int getProtectedValue() { return protectedValue; }
}
So I postulate the existence of annotations for public and package
private getters and setters, and further postulate that protected
methods are left up to the programmer. And private ones to, for that
matter.
A
Arne Vajhøj
Tim said:
Getters and setters are both good design and necessary to work
with common frameworks.
Arne
A
Arved Sandstrom
Tim Smith said:
Well-designed classes provide access to their state to the degree that
access is required. Once your design has established that such access is
necessary, using getter/setter methods is about as good as you can get.
Arguing for syntactically less-verbose forms is something else entirely.
AHS