Home
FAQ
Feedback
Departments
Discussions
(new topic)
Language Evaluation
PL Courses
Research Papers
Design Docs
Quotations
Genealogical Diagrams
|
|
|
|
teaching-learning
| Why Learning Assembly Language is Still a Good Idea |
|
Randall Hyde, author of Art of Assembly and HLA (High Level Assembly), discusses why Assembly language is still relevant. An interesting (and I think) polar opposite of Jame's recent posting on where programmers are frittering away Moore's law.
Often, you'll hear old-time programmers make the comment that truly efficient software is written in assembly language. However, the reason such software is efficient isn't because the implementation language imparts some magical efficiency properties to that software -- it's perfectly possible to write inefficient software in assembly language. No, the real reason assembly language programs tend to be more efficient than programs written in other languages is because assembly language forces the programmer to consider how the underlying hardware operates with each machine instruction they write. And this is the key to learning how to write efficient code -- keeping one's eye on the low-level capabilities of the machine.
On a related front, Cameron Laird and Kathryn Soraiz also discuss HLA in Programming Down to the Silicon and Rapid Development of An Assembler Using Python. (And while I'm dumping my links, I'll also mention the ASM compiler for .Net).
I've tinkered with HLA's OO, and I must say it's strange dealing with classes/methods at the same time you push and pop registers. The main thing, though, that I'd mention is that assembly language is not the only intermediate target machine. For example, Java programmers should understand the intermediate code produced by the compiler (IL for .Net compilers or whatever your target machine happens to be). It's not important to understand how the VM translates into x86, but I consider it important to be able to comprehend how the higher level code translates down into the target machine (virtual or actual).
Posted to teaching-learning by Chris Rathman on 5/9/04; 10:02:11 PM
Discuss (9 responses)
|
|
| Teach Yourself Scheme in Fixnum Days |
|
This is an introduction to the Scheme programming language. It is intended as a quick-start guide, something a novice can use to get a non-trivial working knowledge of the language, before moving on to more comprehensive and in-depth texts.
I was gonna post a bit of Lisp advocacy with Better is Better (a takeoff on the classic Worse is Better) but then that probably wouldn't qualify as playing "Nice". :-)
My end goal is to work through two books that I acquired: EOPL and Lisp in Small Pieces. But I found that I needed to refresh / upgrade my knowledge of Scheme before I can make my way through.
The above tutorial is a nice lean intro to Scheme for those that like their PL material to be concise. In trying to immerse myself in Scheme, I've read SICP (as well as the videos) and am about halfway through The Little Schemer. Any other suggestions for other "must read" Scheme material?
Also, does anyone have a list of the standard library functions and macros that accompany MZScheme? Or at least know a way to query the environment to return the known defines? I want to update my editor to recognize and color the "reserved words".
Posted to teaching-learning by Chris Rathman on 4/6/04; 11:18:43 AM
Discuss (6 responses)
|
|
| Video lectures on SICP |
|
Hadn't seen these on LtU before, and thought it'd be of interest:
These twenty video lectures by Hal Abelson and Gerald Jay Sussman are a complete presentation of the course, given in July 1986 for Hewlett-Packard employees, and professionally produced by Hewlett-Packard Television. The videos have been used extensively in corporate training at Hewlett-Packard and other companies, as well as at several universities and in MIT short courses for industry. These twenty video lectures by Hal Abelson and Gerald Jay Sussman are a complete presentation of the course, given in July 1986 for Hewlett-Packard employees, and professionally produced by Hewlett-Packard Television. The videos have been used extensively in corporate training at Hewlett-Packard and other companies, as well as at several universities and in MIT short courses for industry.
The videos are very large .5 to 1.5 gigs in size each. Not sure my ISP will hold out for that long (i'm halfway through downloading the first now).
Posted to teaching-learning by Chris Rathman on 3/9/04; 7:34:11 PM
Discuss (6 responses)
|
|
| StarLogo: Give the Gift of Learning |
|
Being as I'll be in the process of reading Computer Science Logo Style during the season break, I thought I'd forward on the advertisement of what you should offer the little tykes:
StarLogo is a open-ended environment that allows kids of all ages to create, explore, and learn while having fun. This holiday season, give a gift that keeps on giving -- learn StarLogo with your kids. I hope you have a lot of fun together. Cowabunga, Dudes!
Ok, so your kids probably need to have an inclination for programming languages - my oldest 2 boys would prefer Final Fantasy X-2. But my youngest enjoys exploring on the computer, and I'll be using the software to learn along with her. Of the programming languages that were written for teaching ankle biters (e.g. smalltalk, python), only logo seems to have remained focused on that goal.
Posted to teaching-learning by Chris Rathman on 12/19/03; 9:21:04 AM
Discuss (2 responses)
|
|
| The JPie Interactive Programming Environment |
|
Demo'd at OOPSLA '03...
JPie is an interactive programming environment designed to make the power of Java software development accessible to a wider audience.
In JPie, all aspects of a program's behavior can be modified while the program runs, without the edit-compile-test cycle that routinely bogs down software development. When a class is modified in JPie, even existing objects are affected by the change.
In JPie, you don't describe programs in "code," but instead you directly manipulate their functional components. This enables inexperienced programmers to achieve early success, without the steep learning curve that precedes development in a traditional textual language.
Posted to teaching-learning by Patrick Logan on 11/24/03; 3:28:14 PM
Discuss (4 responses)
|
|
| Dylan Evans: Computer Illiteracy |
|
In 50 years, perhaps much less, the ability to read and write code will be as essential for professionals of every stripe as the ability to read and write a human language is today. If your children's children can't speak the language of the machines, they will have to get a manual job - if there are any left.
I, for one, agree that understanding what programming is about is an essential skill, without which people will be regarded more and more as functionally illiterate. But this really is off topic for LtU.
What concerns me is that many people who think about this issue have a very narrow view of what programming is all about, usually due to exposure to very specific introductory programming languages (i.e., BASIC, Pascal etc.)
Microsoft encourages us to believe that we can force computers to adapt entirely to our preferences for visual images, without having to adapt ourselves to their preference for text.
Much as I'd like to share this sentiment, my intemate knowledge of computers forces me to admit that for the computer text, numbers and visual images (i.e., grpahics) are all the same: long sequences of bits... When I see phrases like computer logic I assume people are thinking of for loops not folds, about pointers and not about infinite data structures, about imperative code and not about direct manipulation languages (more here).
Many people that feel that programming is beyond them, feel at home when creating complex spreadsheet based mini applications.
It seems to me that not only should we educate programmers, and encourage schools to include programming as an integeral part of a liberal education, we should also educate those participating in this debate about the full spectrum of meaning that hides behind the term computer logic.
Posted to teaching-learning by Ehud Lamm on 11/11/03; 8:26:23 AM
Discuss (1 response)
|
|
| Continuations Reading Group |
|
In keeping with the discussions here and in other weblogs on the use of continuations in web interactions, this announcement appeared recently on the LL1 email list.
Continuations have found many applications in the study of programming
languages and (more recently) natural languages. In this reading group,
we will read and discuss papers on continuations from many perspectives...
Posted to teaching-learning by Patrick Logan on 9/15/03; 11:14:06 PM
Discuss (3 responses)
|
|
| Best PL tutorials? |
|
For pedagogical reasons, I've developed a habit of collecting programming language tutorials and introductions. I'm curious to know, then, which ones LtU readers have found most (and least) illuminating, interesting, accessible, insightful, (physically) attractive, professional, etc. and for what reasons.
Frank asked this in the discussion group, as since I am a great fan of language tutorials, I thought I'd share the question with those that (still) only follow the links from the home page.
My mind is elsewhere as the moment (we are planning a little vacation), but I second the recommendation for Teach yourself Scheme in Fixnum days. Another favorite (no flames please) is "A Tutorial Introduction" from K&R's The C Programming Language.
Not esoteric enough? Take a look at the J Dictionary (though one can argue that this is the language definition, and not a tutorial).
Posted to teaching-learning by Ehud Lamm on 9/15/03; 10:59:01 AM
Discuss (3 responses)
|
|
| Practical type inference for arbitrary-rank types |
Haskell's popularity has driven the need for ever more expressive type system features [...]. One such feature is the ability to write functions with higher-rank types - that is, functions that take polymorphic functions as their arguments.
The intended audience is quite wide... it's ended up asa tutorial-style paper rather than one intended for type-system insiders.
[draft, via c.l.f]
Posted to teaching-learning by andrew cooke on 7/7/03; 5:06:29 AM
Discuss
|
|
| OO Weed Languages |
|
Computational Diversity, Practice and a Passion for Applications
Thoughts On Software Education
Dave Thomas
The moment we start believing that there is only one right language, operating system, modeling language, or computational metaphor we are in serious trouble.
link to discussion group posting
Posted to teaching-learning by andrew cooke on 6/26/03; 3:30:33 AM
Discuss
|
|
| Typetool |
I did a Web application for the visualization of the type inference process for the Simple Type System and pure ML.
-- Hugo Simoes on c.l.f
Posted to teaching-learning by andrew cooke on 6/25/03; 5:22:21 PM
Discuss
|
|
| Concepts, Techniques and Models of Computer Programming |
|
Google's cached HTML version can be found here.
From a Slashdot thread:
If you are ready to take on a heroic task and read thru all 976 pages of Concepts, Techniques, and Models of Computer Programming (draft) (pdf file, 3MB, intro here) written by Peter Van Roy and Seif Haridi you won't regret it. Just finished reading it and I feel like I have read the Bible.
With a recomendation like that I couldn't very well ignore it, now could I. From the Preface:
We mention many programming languages in the book and relate them to particular computation models. For example, Java and Smalltalk are based on an object-oriented model. Haskell and Standard ML are based on a functional model. Prolog and Mercury are based on a logic model. Not all interesting languages can be so classified. We mention some other languages for their own merits. For example, Lisp and Scheme pioneered many of the concepts presented here. Erlang is functional, inherently concurrent, and supports fault tolerant distributed programming.
We single out four languages as representatives of important computation models: Erlang, Haskell, Java, and Prolog. We identify the computation model of each language in terms of the book's uniform framework. For more information about them we refer readers to other books. Because of space limitations, we are not able to mention all interesting languages. Omission of a language does not imply any kind of value judgement.
And from the Abstract:
The book is suitable for undergraduate and graduate courses in programming techniques, programming models, constraint programming, distributed programming, and semantics.
At the very least, looks interesting.
Posted to teaching-learning by Dan Shappir on 6/18/03; 1:01:54 PM
Discuss (20 responses)
|
|
| The Little Coder's Predicament |
|
via Slashdot
The old machines don't compare to the desktops of today, or to the consoles of today. But, sadly, current versions of Windows have no immediately accessible programming languages. ... Yes, there are burgeoning free SDKs for many of these platforms. But they are obscure and most children have no means of actually deploying or executing the code on their own hardware! This is obvious to us all and likely doesn't seem such a big deal. But ask yourself what might have happened had you not had access to a programming language on an Atari 800 or a Commodore. You tell me if this is a predicament.
A discussion of the current state of affairs for beginner aspiring programmers. Being an oldie (35), my recollections match those presented in this article (I had a TI-994A as well (a weird, wonderful / terrible machine). OTOH my kids are too young to give me a feel as to the state of things today for teenage programmers.
My feeling is that Web "programming" (DHTML and Macromedia) could compensate of the lack of desktop development environment of beginners. Also, while the writer does mention the Windows scripting host, he neglects to mention HTAs, which make building simple GUI apps rather easy. OTOH he is correct with regard to the lack of examples and documentation (but did I have documentation for the TI's Extended Basic ;-)
Posted to teaching-learning by Dan Shappir on 6/15/03; 1:40:50 AM
Discuss (8 responses)
|
|
| Computer Languages for Secondary Education |
|
The essential idea behind our research is that by using a formal, well-defined language to express objects in a learning domain we can then use computers to provide new ways to explore and experience these objects. This also introduces an element of creativity into the learning experience. We allow students to construct and experiment within a learning domain where they can build and share artifacts.
Finally. Using DSLs in education. I've been waiting for this to happen.
The only ingredient I think is missing is actual language design. I am quite sure high school students are able, and would benefit, from designing and implementing DSLs.
It's up to us to make implementation easy enough. Now that's a research agenda.
(If you didn't guess by now, the people behind this project are the Pan/Haskore guys)
Posted to teaching-learning by Ehud Lamm on 4/9/03; 5:12:45 AM
Discuss (3 responses)
|
|
| "My C++ Experience/Disaster" |
|
After studying C++ for almost a year (at an AP level, what ever that crap is worth), I can do nothing fancy: graphics or anything "cool." Well, nice talking to you, too bad you couldn't invent something more lame.
Excerpt from a letter sent to Bjarne Stroustrup.
Stroustrup's short reply: Thanks. I hope you feel better after having demonstrated your ignorance and bad manners.
I can totally sympathize with Stroustrup, and understand his curt response. The email is indeed very rude.
But still, I think valuable lessons are to be learned. First, how come a student doesn't realize the role of libraries, after taking an AP level course in programming? Yes, this does indicate a certain "incompetence of [the] teachers".
Second, we should all realize the students want to do cool and interesting things while learning computer programming. If the language doesn't allow beginners to do useful stuff, it may not be all that appropriate for beginners. But does the learning curve of industrial strength languages have to be so steep?
Finally, one wonders when universities (and after them highschools) will stop teaching languages based on market share, and instead concentrate on Haskell and Scheme, as we all know they should...
Posted to teaching-learning by Ehud Lamm on 2/23/03; 2:34:45 AM
Discuss (16 responses)
|
|
| Matthias Felleisen:The Human Language Interface (ppt) |
|
While researchers have paid some attention to explaining syntax errors, type errors, and data flow properties, most research efforts focus on type systems, logics, semantics, compilation strategies, register allocation, instruction pipelining, memory locality, etc. In other words, work on the language-machine interface dominates work on the human-language interface. The consequences are bad for both novices and experienced programmers. Novices struggle with an array of bewildering programming and programming language concepts from the very start; professionals who switch from one class of language to another often miss the point of the new language and its program design philosophy.
Yet another presentation about DrScheme and friends.
I always enjoy finding a twin soul, which perhaps explains my delight with PLT's philosophy which begins with the understanding that programming languages are, first and foremost, languages meant for human consumption.
This presentation has little new, if you followed our previous links about PLT, HtDP and DrScheme.
Two points that are always worth mentioning: Less dropouts, especially women, and better results in advanced courses than students with Java only background.
Posted to teaching-learning by Ehud Lamm on 2/6/03; 12:53:06 AM
Discuss (1 response)
|
|
| Rebel with a Cause |
|
Matthias Felleisen wants to change the way students learn to program. He also believes programming should be part of every high school's core curriculum. Don't bet against him.
A behind the scenes look into the birth of TeachScheme!
Since I am in the process of marking exams I can understand the frustration: "We would grade the final product-the programs the students produced-and either they worked or they didn't work. But if the program didn't work, we tried to find some way of giving them proper credit, without knowing whether they had accidentally written down nonsense that looked OK or whether they had just made a little mistake but actually understood what they were trying to accomplish."
I have many questions about and objections to HtDP, but I admire the philosophy and dedication. Don't you?
Posted to teaching-learning by Ehud Lamm on 2/5/03; 6:02:09 AM
Discuss (3 responses)
|
|
| NetLogo |
|
NetLogo is a programmable modeling environment for simulating natural and social phenomena. It is particularly well suited for modeling complex systems developing over time. Modelers can give instructions to hundreds or thousands of independent "agents" all operating in parallel. This makes it possible to explore the connection between the micro-level behavior of individuals and the macro-level patterns that emerge from the interaction of many individuals.
NetLogo is related to StarLogo (details) that was developed at MIT (StarLogo was mentioned here in the past, IIRC).
Not having tried NetLogo, I am intrigued by the BehaviorSpace tool which provides a way to systematically evaluate the way the different parameters of your model interact, and by the HubNet system that provides support for participatory simulations in which each student controls a part of the system by using an individual device.
Posted to teaching-learning by Ehud Lamm on 1/22/03; 3:34:33 PM
Discuss
|
|
| Usability Issues in the Design of Novice Programming Systems |
|
J.F. Pane and B.A. Myers, "Usability Issues in the Design of Novice Programming Systems," Carnegie Mellon University, School of Computer Science Technical Report CMU-CS-96-132, Pittsburgh, PA, August 1996, 85 pages.
In addition to providing a checklist of issues that should be considered in the design of future systems, this report can be used to help researchers identify fruitful topics of future novice programming research.
I haven't read all of this yet (it is way to long for my current work schedule) but some items caught my attention: Choose an Appropriate Metaphor, Effectiveness of Notation is Task Dependent, Support Direct Manipulation and Definition by Example, Choosing a Paradigm, Modularity and Abstraction, Support Secondary Notation, and Aesthetic and Minimalist Design.
Each topic is classified according to its source of justification, be it expert opinion or empirical studies. This is vrey helpful. Each topic also includes a list of references.
But perhaps the most important thing is that each suggestion includes a section the lists exceptions to the proposed guideline.
Designing guidelines for language and IDE design is hard to do well, it seems these guys managed to stay clear of some of the obvious traps.
Posted to teaching-learning by Ehud Lamm on 12/3/02; 2:10:57 AM
Discuss
|
|
| Programming languages textbook online |
This is a textbook for a programming languages class, focusing on basic type theory and the implementation of (mostly) functional languages. It's sort of a cross between to Pierce's Types in Programming Languages and Friedman et. al.'s Essentials of Programming Languages. It has a nice introduction to type theory and operational semantics, and has implementations of several toy languages done in ocaml. Best of all, it's totally free! ;-)
Posted to teaching-learning by Michael Vanier on 9/24/02; 4:53:38 PM
Discuss (6 responses)
|
|
| Bricklin: Why Johnny can't program |
|
As a result of the Trellix blogging announcement I have been involved in a flurry of discussions with people about blogging, about various tools and features, and about differentiating the various blogging systems. One thing that came up in a discussion with Amy Wohl, as a follow up to her article about the Trellix offering, was this question: "How do you explain that function accessible through programming and function designed for consumers is not exactly the same thing?" Here are some of my thoughts
This is somewhat related to the idea of end-user programming.
End-user programming, PBD, and direct manipulation languages, are somewhere along the line between programming and conventional user interfaces.
Posted to teaching-learning by Ehud Lamm on 9/17/02; 11:14:27 AM
Discuss (12 responses)
|
|
| Structure and Interpretation of Computer Science Curriculum |
|
Matthias Felleisen, Robert B. Findler, Matthew Flatt, and Shriram Krishnamurthi. The Structure and Interpretation of the Computer Science Curriculum. Functional and Declarative Programming in Education (FDPE2002). October 2002
The authors of HTDP explain why they prefer it over the venerable SICP.
Along the way they explain the choice of Scheme, and the pedagogic ideas behind the design of DrScheme.
Designing a first course in CS is very hard, and I find the work done on HTDP adimarble. Alas, reading this I find myself preferring the choices leading to SICP.
I think that a first course should not be about program design (which tends to foucs on things like programming-in-the-large, and reuse), but rather about computational models (e.g., nondeterminism and laziness). In this way the first course introduces the field of computer science, which deals with many issues beside programming and program design.
Designing an introductory course is about making choices, and though I would have made different choices, I find both this paper and the approach it argues well worth considering.
(PostScript version of the paper is available)
Posted to teaching-learning by Ehud Lamm on 9/2/02; 4:27:06 AM
Discuss (5 responses)
|
|
| Why American Computer Science Seems Incurable |
|
Dijkstra talks about how
teaching and research in American computer science
suffers from industrial pressure and influence
pursuing a "dream of full automation."
This bad influence is reflected in an
interview with a faculty candidate who:
"...did not claim that he had gained any new insights
or that you could learn anything interesting from studying his thesis,
and the sole justification was to be found in his final product...
this software was very important because (i) there were thousands of
Fortran programs 'out there', and (ii) the system was
fully automatic, an absolute requirement for industrial
acceptance...
his gadget worked in such a small set of circumstance that
its main feature became that one could apply it unthinkingly."
Dijkstra also sees the widespread idea in corporate America
of technical employees being replacable
like a part or a light bulb as a barrier to
brilliant and innovative scientists.
The essay raises the question:
Should academic research be judged on how it improves
teachable material or by industrial acceptance?
Posted to teaching-learning by jon fernquest on 8/23/02; 1:38:13 AM
Discuss (2 responses)
|
|
| Scheme-robo -- automatic assessment for Scheme exercises |
|
(via comp.lang.scheme)
Basically, Scheme-robo takes as input a solution to an exercise (usually written by a student and submitted to the system in some way) and some exercise-specific configuration. Scheme-robo does various kinds of tests (e.g., test runs) on the solution and returns a number of points and a set of comments to be given to the student.
Not very exciting (but seems like a useful thing to have around...)
Scheme-robo executes student code in a metacircular Scheme interpreter. Thus, test runs are specified as Scheme procedure calls, and the actual return value is usually compared to a set of correct solutions. The comparison is usually done with a standard equality predicate. Thus, there is no need for student code to read input or print out values, and we avoid the problem of parsing output written by student code. The metacircular interpreter also gives us a ``sandbox'' where student code can be safely executed: the interpreter does not include potentially dangerous features such as file I/O.
Another use for metacircular interpreters. Nice.
Posted to teaching-learning by Ehud Lamm on 4/23/02; 7:16:12 AM
Discuss
|
|
| Norvig: Teach Yourself Programming in Ten Years |
|
Researchers (Hayes, Bloom) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. Samuel Johnson thought it took longer than ten years: "Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price."
I am sure each of us has his own opinions about leanring how to program (My answer: you either get it, or you don't...), but since this site is dedicated to programming languages I just want to draw your attention to the fact that many of the activities mentioned in this essay are directly related to programming languages: "Learn at least a half dozen programming languages" and "Get involved in a language standardization effort" are just two of them.
Indeed, there's no programming without programming languages. This seems like a trivial statement, but it is one of the few profound truths in CS.
Posted to teaching-learning by Ehud Lamm on 2/26/02; 9:48:34 AM
Discuss (2 responses)
|
|
| Revisiting an old thread: choosing a foundation language |
|
I'd love to hear more opinions on this issue. I guess more readers experienced graduates that started programming learning Java; maybe others encountered students who started with Python.
Which language would you choose, and why?
We already know some prefer to use Squeak...
BTW: Any recent data on the popularity of various foundation languages?
Posted to teaching-learning by Ehud Lamm on 1/27/02; 2:45:50 PM
Discuss (23 responses)
|
|
| Book: Python How to Program |
|
Another Deitels book. Keith doesn't like them (to put it mildly).
I had a look at the Java book and wasn't impressed. Seems to me that if you give an example showing an improper (LSP-wise) inheritance relation between Circle and Ellipse, and don't (at least) explain the issues involved, you are doing your readers a disservice.
What do you guys think about these books?
Posted to teaching-learning by Ehud Lamm on 1/23/02; 9:47:54 AM
Discuss (6 responses)
|
|
| GaTech SqueakEnd 2002 |
|
CALL FOR PARTICIPATION:
CS FACULTY, PRESENTERS, AND SQUEAKERS
NSF-SPONSORED
WORKSHOP ON THE INTEGRATION OF MULTIMEDIA
CONSTRUCTION IN COMPUTER SCIENCE EDUCATION
USING SQUEAK
=AND=
ATLANTA SQUEAKEND
May 3-5, 2002
College of Computing
Georgia Institute of Technology
The tentative schedule looks interesting.
But using Squeak as a first language? Now that's courage. I was stoned for even proposing such mainstream languages as Haskell and Scheme. I can just hear them: "Squeak? What's Squeak? Oh. It's Smalltalk? Well Java is better isn't it?"
Posted to teaching-learning by Ehud Lamm on 1/19/02; 2:22:22 AM
Discuss (8 responses)
|
|
| Beseme Project Overview |
|
(seen on the Haskell mailing list)
Beseme is about teaching discrete math using functional programing (Haskell, to be exact). The basic idea is to teach CS1 topics in a more mathematical and rigorous way, mainly by introducing proofs and fomral definitions. Functional programming obviously helps, since it makes reasoning about programs so much easier.
This is closely related to some ideas I've been thinking about for some time now. To put it bluntly, after traditional CS1 courses it is a small wonder that some people actually manage to produce reliable software.
Visit the Beseme project home page.
Posted to teaching-learning by Ehud Lamm on 11/22/01; 3:54:37 AM
Discuss (8 responses)
|
|
| BlueJ - The interactive Java environment |
BlueJ is an integrated Java environment specifically designed for introductory teaching
BlueJ supports:
- fully integrated environment
- graphical class structure display
- graphical and textual editing
- built-in editor, compiler, virtual machine, debugger, etc.
- easy-to-use interface, ideal for beginners
- interactive object creation
- interactive object calls
- interactive testing
- incremental application development
BlueJ tries to deal with some of the problematic features of Java for introductory teaching. If one must use Java, maybe this can help...
Or maybe you should choose Squeak 
Posted to teaching-learning by Ehud Lamm on 11/3/01; 11:20:13 AM
Discuss (1 response)
|
|
| Role of Programming Languages Study in Programmer Education |
|
An insipiring talk by Daniel Friedman. The text of the lecture is also available, as is the example code.
A large part of the talk shows how you can overcome Java's lack of proper tail calls by CPS, registerization and trampolining.
The lecture is built around letters from from students, that talk about what they gained from studying programing language theory. These range from getting a high grade in another course, to winning big in the dot com era.
Since I am teaching from EOPL2 I found the quotes from former students to be very motivating, but I suspect they can be also quite inspiring for newcomers and students.
Posted to teaching-learning by Ehud Lamm on 10/29/01; 9:21:30 AM
Discuss
|
|
| Learning a new programming language |
|
Nothing spectacular in this JavaLobby discussion, but since I got somewhat involved in the discussion, I thought I'd mention it here. Being JavaLobby, it's not a surprise that some of the participants think that Java is a good candidate. Personally, I think Java is a terrible first language - I'd even go as far as recommending VB over Java as a first language.
A first programming language should cover two territories. First, the positive feedback should be immediate without having to delve into a lot of intricacies beforehand - languages like VB, Python & Perl do this well. Kind of like the ability of small children to use the spoken word to get things accomplished way before they become fluent in the intricacies of the written word.
Second, this programming language should also impart the principles of programming - Pascal, Smalltalk & Scheme do this well. As I said in the thread, professional software developers will wind up having to learn more than one language.
The real question, though, is whether a person's first programming language has long term ramifications on a person's long term capacity to think logically? Perhaps my experience is unique, but the hardest language for me to learn was the third. The first two were as different as night and day, but the third contained ideas present in the first two and made matters somewhat confusing.
Posted to teaching-learning by Chris Rathman on 6/5/01; 1:07:54 AM
Discuss (12 responses)
|
|
|
