NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies:
67 -
Pages:
5
[
12345
| Next
]
Threads:
[
Previous
|
Next
]
There's been a lot of talk over the years discussing various languages and their merits as an "intro language". This is a surprisingly important decision because of the extreme difficulties of "getting into" the software development industry. There's a ton of stuff to learn above and beyond the language and the last thing you want is to spend all of your efforts trying to figure out some weird syntactical detail.
James Gosling, the father of Java, recently did a
brief clip
talking about how Java is an excelent first language. I have to admit, I've given the same speech a few times myself. "Java's pretty straightforward." "It gives you OOP without anything to get in the way." Frankly, I still feel to some extent that Java may be the best language to get a new developer started. However, times change...
Since the inception of Java, we've seen the rise of far more expressive languages like Ruby or Python. We've even seen the rise of languages on the same level as Java which have arguably superior syntax and capabilities (eg Scala). Considering that Java as a language may or may not be on the decline (given its age), perhaps it would be better to put students into one of these other, more "hip" languages?
Personally, I still agree with what James is saying. For all its flash and importance, Ruby's still a pretty complicated language. Under it's clean, expressive exterior lurks monster after monster of weird inconsistencies (think lack of type coercion and 800 ways to do exactly the same thing). That's exactly the sort of thing that newbie developers need to avoid. On top of that (and perhaps more importantly), Java has a *massive* tool space. There are more and better tools for Java than any other language in the history of development, and I would defy anyone to say otherwise. New developers want the lowest possible entry requirements for using a language. Solid tools like Eclipse, NetBeans or IntelliJ provide this sort of support. For a new developer, you can even go one step further and use BlueJ, which is arguably an easier IDE for beginners. To my mind, the language with the best tools wins the spot as "best first language".
So what do you think? Is Java really the best language to learn your first time out? Possibly more significant question, do the schools agree? Most schools I've seen try to teach C or C++ to beginner programmers. Shouldn't they be using Java instead?
Yes I do think Java is the best candidate.It does enforce a discipline, good exception handling habits, very solid libraries, abundant free tools, unit testing, easy multi-threading and networking. No contest.
Sorry but Ruby ,Python and Scala have awkward syntax.
Groovy would be a much better choice, than those 3.
It depends what you mean by 'intro language'. If we are talking about showing basics to smart teenagers, I would agree. As far as IT studies are concerned, I'm still all for the old school - start with assembly, go through C and only then let people choose their favorite language. I would still force everybody to spend at least few lessons with each java, c++, smalltalk, lisp and prolog regardless of what they choose.
Why assembler and C? To weed out people who cannot understand what a pointer is. OO is all great, but there is way too many people who have no grasp of layers below. Going on higher abstraction level should be a choice one make to manage the complexity, not a choice which is forces by ones ignorance of details.
> Since the inception of Java, we've seen the rise of
> far more expressive languages like Ruby
Ah, you sound like a youngster that doesn't know what preceded Java and the deficiencies overcome by some of the design choices in Java.
If you are interested, look at Smalltalk or its modern descendant Squeak. Remember that Smalltalk-80 was usable 16 years before Java arrived. Also remember that critical tools were developed in Smalltalk a decade before they arrived in Java (specifically, refactoring browsers and source control tools for OO languages).
I'll leave the greybeards to describe how LISP was 10 years ahead of Smalltalk.
> Sorry but Ruby ,Python and Scala have awkward
> syntax.
> Groovy would be a much better choice, than those 3.
The problem is that Groovy is basically Java except not really. It's basically a very powerful, dynamic scripting extension to the Java syntax. That sort of mucking about with derived syntaxes and so on confuses new developers to no end. Ruby's syntax is certainly cryptic at times, but it has the advantage that it's difficult to confuse with other languages.
(incidentally, Scala suffers from a similar problem as Groovy, just not so much due to its highly functional nature)
> Why assembler and C? To weed out people who cannot
> understand what a pointer is. OO is all great, but
> there is way too many people who have no grasp of
> layers below. Going on higher abstraction level
> should be a choice one make to manage the complexity,
> not a choice which is forces by ones ignorance of
> details.
Poppycock.
Nowadays, you go with the inverse Peter Principal. People work down to their level of incompetence as they lose the abstractions.
Start them high and work down.
Why?
Higher level languages are (obviously) much easier to use, and users are productive with them much more quickly. Quick turn around of fast successes builds excitement to try and learn more, and encourages experimenting, and thus more learning.
The better their successes, the deeper in the pond they go. Starting them off on the deep end with concrete waders today is foolish.
Should programmers understand the raw bits beneath the sugar frosting of modern development systems? Hmm...maybe.
Here's the thing.
I want more programmers, not less. I want more BAD programmers than an elite few good ones. I am a flag waving, mountain top hollerin' proponent of bad practices done by end users who don't know what they're doing, but somehow manage to be productive anyway. Doctors and Marketers pounding out VBA in Excel, or hacking Filemaker Pro, or Science Teachers making crude animations in Hypercard. Bulls in the CPU's china shop of limited resources.
Whatever. Anything that makes that stone stupid box sitting at their feet something more than an inefficient room heater.
Because programming empowers the user to leverage their computer for something besides a smart typewriter, or a bad television. Automating whatever drudgery the users thinks they can get the machine to do.
There are a bazillion tasks that junior programmers can do today using high level tools.
My favorite anecdote was of a programmer at an old company, he'd just finished some small DB front end using Delphi with a half dozen screens or so.
We were talking about it and he chimed in "One thing still confuses me. I don't understand the difference between RAM and disk".
As a seasoned grognard, you can imagine the abject horror when I learned that this kid effectively knew nothing about how a computer works. Thinking back to the days talking about architectures and system bus structure with my Dad in the car, while reading all of the Osbourne books and every data sheet I can get my hands on like of treasures like the Fairchild F8, or the RCA 1802.
Laughing hysterically when my Father pointed out that on the TRS-80 the Bus Request bin was HARDWIRED to tri-state buffers between the CPU and the RAM, so by simply ASKING for a Bus Request for, say, DMA, the memory instantly vanished from the CPU, even if it was mid cycle. Oops. Would be better wired to the Bus Acknowledge pin. 80K floppys, electrostatic printers, computers that turn the TV in to snow when you turn them on. You know, the "Good ol days".
But, then, thinking it through, think about what he accomplished having no idea how a computer worked. He created an application that's going to save some poor soul somewhere some time. Eliminated a little bit of drudgery, reciept counting, folder stuffing, who knows what, from someplace.
That's a good thing. His app worked. It does the job. It was a fine example of fields and buttons and DB bits. So who cares that he doesn't know RAM from hard drive.
And thats the power of it all. The fact that a new guy like this can pound out an effective application is far more important to getting value out of computers than understanding cache hits, clock cycles or what registers can be used for indexed operations. Screw pointers! Good riddance to them I say!
Teach the damn machines to work with us better rather than teaching us to work with them better. Enslave them all and code them in to submission is my credo. There is no Us and Them, there's just Us. I don't even raise these machines to the level of a "them".
So, teach them something high level, get them excited at:
10 PRINT "GABES A GEEK"
20 GOTO 20
(Which is another anecdote with interesting consequences from my past.)
Folks who "get it", who dig this work, who want to learn and know it better will drive deeper and deeper into the vast array of complexity that is modern computing. But let them drive there at their own rate, and drive as far as they want to go rather than scaring them all off in the first place.
> As a seasoned grognard, you can imagine the abject
> horror when I learned that this kid effectively knew
> nothing about how a computer works. Thinking back to
> the days talking about architectures and system bus
> structure with my Dad in the car, while reading all
> of the Osbourne books and every data sheet I can get
> my hands on like of treasures like the Fairchild F8,
> or the RCA 1802.
That's as deep as you went with your dad? Huh! These days we start from quantum physics and N and P type semiconductors, before we work up to transistors, registers and logic gates
Basic? Umm... NO. I started on that and when you talk about idiosyncrasies, it's got plenty. Pascal would be much better, but...
When you talk about a language for starters, it's necessary to ask which age group it will address. For me, it's Logo for elementary school kids, and Python for older students. You mentioned that Ruby has strange syntax and follows the "more than one way to do it" philosophy. Well, Python has the opposite mantra- there's one (best practice) way to do it, which should make it suitable for beginners.
As for Java, I think it's better than C/C++ as a starting language. One should eventually drill her/his way down to C and Assembler (and not all the gory details are necessary). I agree with Will Hartung above that you should start with more abstract and easy and then gradually go deep in the details. Universal concepts are important to learn first rather than some weird low-level implementation, which would vary on a different language/architecture.
> That's as deep as you went with your dad? Huh! These
> days we start from quantum physics and N and P type
> semiconductors, before we work up to transistors,
> registers and logic gates ;-)
You probably meant is as a joke, by on my IT university we indeed were going through entire path from semiconductors at electron level up to microprocessors - fortunately in parallel to going from assembler to java and 4GL.
I still think about all the electronics majorly as waste of time, but there was a class which I think was quite useful to my understanding of multithreading at the moment - we were working with basic gates/clocks and connecting them using wires (on boards looking like old phone 'manual' switches). Getting few race conditions and hazards on the level of blinking lights helps to understand the problems with memory synchronization
&> Nowadays, you go with the inverse Peter Principal.
> People work down to their level of incompetence as
> they lose the abstractions.
>
> Start them high and work down.
[...]
I fully agree with you for the need for underqualified coders. But on the other hand, I don't think you need an university degree to produce delphi db frontends - 2-3 years school at age of 15-16 should be enough (similar to the way shoemakers or bakers are 'produced').
Maybe better comparison is building site. I still think that architects and main overseers(?) on the building site should have reasonably good overview of material tension, forces/whatever is needed - on the other hand, hundreds of workers putting bricks together don't have to. But you don't have to put brick workers through 5 years university.
Even modern science doesn't have the answer to all questions, but that doesn't stop us sending satellites into space and other high-level abstractions of physics fundamentals.
> Yes I do think Java is the best candidate.It does
> enforce a discipline, good exception handling habits,
> very solid libraries, abundant free tools, unit
> testing, easy multi-threading and networking. No
> contest.
I generally agree, although I'd nuance it by saying that although it's easy to multi-thread if you know what you're doing, it's also easy to get in a mess
Many people criticise checked exceptions, and even although it's only the compiler that enforces them, they're an excellent way of encouraging stability (although if you forget to free resources in a "finally" block or if you swallow the exception, too bad).
The principles and APIs of Java are relatively easy to grasp, failures are generally less catastrophic than with lower-level languages, and you avoid getting into difficulties with some of the power features of scripting languages.
Annotations are a good feature in Java (as are .NET attributes in the .NET world) if implemented wisely, in that you can understand all functionality by looking at one source file. Things like ORM mapping via XML, dependency injection, AOP, and meta object protocols, can complicate understanding for a beginner, because although they give an impression of simplified code, you need to look at multiple files to understand what's really going, although they're all undoubtedly useful when well-documented and used and maintained by suitably-skilled people.
Java as a First Language
URL: James Gosling
At 3:40 PM on Aug 30, 2007, Daniel Spiewak wrote:
Fresh Jobs for Developers Post a job opportunity
James Gosling, the father of Java, recently did a brief clip talking about how Java is an excelent first language. I have to admit, I've given the same speech a few times myself. "Java's pretty straightforward." "It gives you OOP without anything to get in the way." Frankly, I still feel to some extent that Java may be the best language to get a new developer started. However, times change...
Since the inception of Java, we've seen the rise of far more expressive languages like Ruby or Python. We've even seen the rise of languages on the same level as Java which have arguably superior syntax and capabilities (eg Scala). Considering that Java as a language may or may not be on the decline (given its age), perhaps it would be better to put students into one of these other, more "hip" languages?
Personally, I still agree with what James is saying. For all its flash and importance, Ruby's still a pretty complicated language. Under it's clean, expressive exterior lurks monster after monster of weird inconsistencies (think lack of type coercion and 800 ways to do exactly the same thing). That's exactly the sort of thing that newbie developers need to avoid. On top of that (and perhaps more importantly), Java has a *massive* tool space. There are more and better tools for Java than any other language in the history of development, and I would defy anyone to say otherwise. New developers want the lowest possible entry requirements for using a language. Solid tools like Eclipse, NetBeans or IntelliJ provide this sort of support. For a new developer, you can even go one step further and use BlueJ, which is arguably an easier IDE for beginners. To my mind, the language with the best tools wins the spot as "best first language".
So what do you think? Is Java really the best language to learn your first time out? Possibly more significant question, do the schools agree? Most schools I've seen try to teach C or C++ to beginner programmers. Shouldn't they be using Java instead?
67 replies so far (
Post your own)
Re: Java as a First Language
Yes I do think Java is the best candidate.It does enforce a discipline, good exception handling habits, very solid libraries, abundant free tools, unit testing, easy multi-threading and networking. No contest.Sorry but Ruby ,Python and Scala have awkward syntax.
Groovy would be a much better choice, than those 3.
Assembler and C
My 0.02$.It depends what you mean by 'intro language'. If we are talking about showing basics to smart teenagers, I would agree. As far as IT studies are concerned, I'm still all for the old school - start with assembly, go through C and only then let people choose their favorite language. I would still force everybody to spend at least few lessons with each java, c++, smalltalk, lisp and prolog regardless of what they choose.
Why assembler and C? To weed out people who cannot understand what a pointer is. OO is all great, but there is way too many people who have no grasp of layers below. Going on higher abstraction level should be a choice one make to manage the complexity, not a choice which is forces by ones ignorance of details.
Re: Java as a First Language
> Since the inception of Java, we've seen the rise of> far more expressive languages like Ruby
Ah, you sound like a youngster that doesn't know what preceded Java and the deficiencies overcome by some of the design choices in Java.
If you are interested, look at Smalltalk or its modern descendant Squeak. Remember that Smalltalk-80 was usable 16 years before Java arrived. Also remember that critical tools were developed in Smalltalk a decade before they arrived in Java (specifically, refactoring browsers and source control tools for OO languages).
I'll leave the greybeards to describe how LISP was 10 years ahead of Smalltalk.
Re: Java as a First Language
> Sorry but Ruby ,Python and Scala have awkward> syntax.
> Groovy would be a much better choice, than those 3.
The problem is that Groovy is basically Java except not really. It's basically a very powerful, dynamic scripting extension to the Java syntax. That sort of mucking about with derived syntaxes and so on confuses new developers to no end. Ruby's syntax is certainly cryptic at times, but it has the advantage that it's difficult to confuse with other languages.
(incidentally, Scala suffers from a similar problem as Groovy, just not so much due to its highly functional nature)
ActiveObjects: an Easier Java ORM; Fuse: Resource Injection for Java
Re: Java as a First Language
My "intro language" is basic,It's easy for a child.
But if you need a working programming,I think java is the best.
Java Swing
Basic or Pascal
> I'll leave the greybeards to describe how LISP was 10> years ahead of Smalltalk.
Arr you beat me to (sarcastically) recommend LISP before certain individuals (whom I shall not name) will surely do!!
My recommendation for an absolute beginner would be Basic or Pascal.
Re: Assembler and C
> Why assembler and C? To weed out people who cannot> understand what a pointer is. OO is all great, but
> there is way too many people who have no grasp of
> layers below. Going on higher abstraction level
> should be a choice one make to manage the complexity,
> not a choice which is forces by ones ignorance of
> details.
Poppycock.
Nowadays, you go with the inverse Peter Principal. People work down to their level of incompetence as they lose the abstractions.
Start them high and work down.
Why?
Higher level languages are (obviously) much easier to use, and users are productive with them much more quickly. Quick turn around of fast successes builds excitement to try and learn more, and encourages experimenting, and thus more learning.
The better their successes, the deeper in the pond they go. Starting them off on the deep end with concrete waders today is foolish.
Should programmers understand the raw bits beneath the sugar frosting of modern development systems? Hmm...maybe.
Here's the thing.
I want more programmers, not less. I want more BAD programmers than an elite few good ones. I am a flag waving, mountain top hollerin' proponent of bad practices done by end users who don't know what they're doing, but somehow manage to be productive anyway. Doctors and Marketers pounding out VBA in Excel, or hacking Filemaker Pro, or Science Teachers making crude animations in Hypercard. Bulls in the CPU's china shop of limited resources.
Whatever. Anything that makes that stone stupid box sitting at their feet something more than an inefficient room heater.
Because programming empowers the user to leverage their computer for something besides a smart typewriter, or a bad television. Automating whatever drudgery the users thinks they can get the machine to do.
There are a bazillion tasks that junior programmers can do today using high level tools.
My favorite anecdote was of a programmer at an old company, he'd just finished some small DB front end using Delphi with a half dozen screens or so.
We were talking about it and he chimed in "One thing still confuses me. I don't understand the difference between RAM and disk".
As a seasoned grognard, you can imagine the abject horror when I learned that this kid effectively knew nothing about how a computer works. Thinking back to the days talking about architectures and system bus structure with my Dad in the car, while reading all of the Osbourne books and every data sheet I can get my hands on like of treasures like the Fairchild F8, or the RCA 1802.
Laughing hysterically when my Father pointed out that on the TRS-80 the Bus Request bin was HARDWIRED to tri-state buffers between the CPU and the RAM, so by simply ASKING for a Bus Request for, say, DMA, the memory instantly vanished from the CPU, even if it was mid cycle. Oops. Would be better wired to the Bus Acknowledge pin. 80K floppys, electrostatic printers, computers that turn the TV in to snow when you turn them on. You know, the "Good ol days".
But, then, thinking it through, think about what he accomplished having no idea how a computer worked. He created an application that's going to save some poor soul somewhere some time. Eliminated a little bit of drudgery, reciept counting, folder stuffing, who knows what, from someplace.
That's a good thing. His app worked. It does the job. It was a fine example of fields and buttons and DB bits. So who cares that he doesn't know RAM from hard drive.
And thats the power of it all. The fact that a new guy like this can pound out an effective application is far more important to getting value out of computers than understanding cache hits, clock cycles or what registers can be used for indexed operations. Screw pointers! Good riddance to them I say!
Teach the damn machines to work with us better rather than teaching us to work with them better. Enslave them all and code them in to submission is my credo. There is no Us and Them, there's just Us. I don't even raise these machines to the level of a "them".
So, teach them something high level, get them excited at:
(Which is another anecdote with interesting consequences from my past.)
Folks who "get it", who dig this work, who want to learn and know it better will drive deeper and deeper into the vast array of complexity that is modern computing. But let them drive there at their own rate, and drive as far as they want to go rather than scaring them all off in the first place.
Re: Assembler and C
> As a seasoned grognard, you can imagine the abject> horror when I learned that this kid effectively knew
> nothing about how a computer works. Thinking back to
> the days talking about architectures and system bus
> structure with my Dad in the car, while reading all
> of the Osbourne books and every data sheet I can get
> my hands on like of treasures like the Fairchild F8,
> or the RCA 1802.
That's as deep as you went with your dad? Huh! These days we start from quantum physics and N and P type semiconductors, before we work up to transistors, registers and logic gates
Re: Java as a First Language
Java makes a fine first language. It's not perfect, but then again neither are the alternatives.A good education would include Java, C++, and a small bit of Assembler, IMO.
Re: Basic or Pascal
Basic? Umm... NO. I started on that and when you talk about idiosyncrasies, it's got plenty. Pascal would be much better, but...When you talk about a language for starters, it's necessary to ask which age group it will address. For me, it's Logo for elementary school kids, and Python for older students. You mentioned that Ruby has strange syntax and follows the "more than one way to do it" philosophy. Well, Python has the opposite mantra- there's one (best practice) way to do it, which should make it suitable for beginners.
As for Java, I think it's better than C/C++ as a starting language. One should eventually drill her/his way down to C and Assembler (and not all the gory details are necessary). I agree with Will Hartung above that you should start with more abstract and easy and then gradually go deep in the details. Universal concepts are important to learn first rather than some weird low-level implementation, which would vary on a different language/architecture.
Re: Assembler and C
> That's as deep as you went with your dad? Huh! These> days we start from quantum physics and N and P type
> semiconductors, before we work up to transistors,
> registers and logic gates ;-)
You probably meant is as a joke, by on my IT university we indeed were going through entire path from semiconductors at electron level up to microprocessors - fortunately in parallel to going from assembler to java and 4GL.
I still think about all the electronics majorly as waste of time, but there was a class which I think was quite useful to my understanding of multithreading at the moment - we were working with basic gates/clocks and connecting them using wires (on boards looking like old phone 'manual' switches). Getting few race conditions and hazards on the level of blinking lights helps to understand the problems with memory synchronization
Re: Assembler and C
&> Nowadays, you go with the inverse Peter Principal.> People work down to their level of incompetence as
> they lose the abstractions.
>
> Start them high and work down.
[...]
I fully agree with you for the need for underqualified coders. But on the other hand, I don't think you need an university degree to produce delphi db frontends - 2-3 years school at age of 15-16 should be enough (similar to the way shoemakers or bakers are 'produced').
Maybe better comparison is building site. I still think that architects and main overseers(?) on the building site should have reasonably good overview of material tension, forces/whatever is needed - on the other hand, hundreds of workers putting bricks together don't have to. But you don't have to put brick workers through 5 years university.
Re: Assembler and C
Even modern science doesn't have the answer to all questions, but that doesn't stop us sending satellites into space and other high-level abstractions of physics fundamentals.Re: Java as a First Language
> Yes I do think Java is the best candidate.It does> enforce a discipline, good exception handling habits,
> very solid libraries, abundant free tools, unit
> testing, easy multi-threading and networking. No
> contest.
I generally agree, although I'd nuance it by saying that although it's easy to multi-thread if you know what you're doing, it's also easy to get in a mess
Many people criticise checked exceptions, and even although it's only the compiler that enforces them, they're an excellent way of encouraging stability (although if you forget to free resources in a "finally" block or if you swallow the exception, too bad).
The principles and APIs of Java are relatively easy to grasp, failures are generally less catastrophic than with lower-level languages, and you avoid getting into difficulties with some of the power features of scripting languages.
Annotations are a good feature in Java (as are .NET attributes in the .NET world) if implemented wisely, in that you can understand all functionality by looking at one source file. Things like ORM mapping via XML, dependency injection, AOP, and meta object protocols, can complicate understanding for a beginner, because although they give an impression of simplified code, you need to look at multiple files to understand what's really going, although they're all undoubtedly useful when well-documented and used and maintained by suitably-skilled people.
- Chris