Slashdot Mirror

Squeak smalltalk is a briliant language for smalls. Runs on all small computers under your o/s of choice. Your work will be completely shareable because the Virtual Machine is identical on all hardware platforms. It leads on to the the most productive language ever created.

Squeak smalltalk for kids

Squeak smalltalk for grownups

Smalltalk for business

Smalltalk for engineers - Very fast.

There are many others, have a look through The Smalltalk Portal.

Just remember that with 30 years of developemnt it just works!

There is always Squeek (Squeek.org, I think) that is a free and very friendly Small Talk. There is a book out on squeek right now that is like "Flatland." I think it is called "Squeek - A trip into object land." It comes with the squeek CD.

You can sue all you want, but it doesn't mean that are right or that you will win.

Apple sued, but they lost., because Apple was not the inventor or the GUI interface. They borrowed the GUI idea from the Smalltalk project which was created by Xerox and PARC.

So the first reason for "plan first, then code" is that coding is expensive. That expense represents a risk if you're pursuing an approach that doesn't work out. Throwing away a plan is quicker and less expensive.

The second reason for "plan first, then code" is that a written plan is a clear expression of the ideas in the plan. Code is often not very readable or very obvious, and a large body of code may require weeks or months of study to get all the nuances at work.

There is a hidden disadvantage to "plan first, then code". Remember that we're trying to manage the risk of choosing a dead-end approach, so we want to minimize the investment before the discovery that the approach is bogus. A non-executable plan won't catch all the design bugs. It will only catch the design bugs that you can recognize on inspection of a written plan; the screening process is limited by your own human cognitive faculties.

What if we could write an executable plan, in a language that is clear and expressive, and in which writing the plan is inexpensive? This would be the best of all possible worlds! Luckily you're not the first person to face a daunting software design challenge, and people have been designing languages for exactly these constraints for many years (Python, Perl, Scheme, Ruby, Smalltalk, and others. These languages vary in the expressiveness of their syntax. If you're concerned about the mental expense of coding, you probably will want to avoid Perl (which looks a lot like C) and Scheme (which requires a mental paradigm shift). My off-the-cuff recommendation among these would be Python.

Why not write your final product in one of these easy, inexpensive, readable, expressive languages? Alas, many of them don't have the performance of C or C++. If you're doing something computation-intensive, that matters. But wait! There is another saving grace, called SWIG, a program that lets you glue small bits of C or C++ code into your larger program written in one of the easy languages.

In most computer programs, the performance is gated by a small number of small pieces of the code. Usually, the majority of the code does not have a big impact on performance. If you can identify those small performance-expensive bits, and translate them to C or C++ and glue them back into your program, you get the speed you want, and 95% of your code is still readable and expressive, and easy to change later. The trick to finding these performance-limiting bits is called profiling (see 1, 2, 3).

So here's the advice (assuming Python):
1. Spend a day learning Python, two days if you're busy. Python has lots of great libraries, skim the list of libraries as somebody may have contributed something you'll need.
2. Write your entire program readably in Python. Don't worry about speed yet. Rewrite as required until you're sure you've got a good design.
3. Use profiling to locate the few small pieces that slow down your program.
4. Use SWIG and C/C++ to rewrite those pieces and connect them back into your program.

Yeah, not like there are any other examples of open source software based on proprietry software.

tlhf

xxx

Also, your linked article talks about a compiler which compiles itself. IE, GCC recognising GCC. Having GCC regocnise BCC, VC++, et al would be insanly difficult. Even more so in this case as Mono is being released after the Microsoft compiler.

It is absolutelly useless, and dangerous too, to choose a development platform before addressing the nature of the problem. There is no language and development platform suitable for every class of problem, no matter what MS, Sun etc. are saying. Another issue you should address your development process, and how the various development platforms suit in the process.

That said, I suggest you may investigate also SmallTalk. Once you get the hang on the language, you'll find it has one of the most productive IDEs ever created.

just read this
(It's not like I want to spend an hour pimping a language when there's a site devoted to it.)

All I need is a motivation.

Just like when I understood the idea of inheritance and the real OO code reuse, together with the idea of moving data to the foreground and that with a good data you need simple algorithms -- that day I understood, that I have to learn Smalltalk, Objective C, C++ and OO Perl.

Today I need to know why I need to learn how to think with the functional paradigm. It's a serious problem, which stops many people before they learn functional languages.

Many years ago I was writing C programs to process text, and I could do everything that way, I just didn't realize, that there were better ways to do the same. That was before I knew Regular Expressions, egrep, sed or Perl. Now I write Perl one-liners for tasks, which used to take me days of writing C code, but I didn't know that before, because "If the only tool you have in the toolbox is a hammer - every problem looks like a nail."

So now I ask for a reason to learn the functional way of thinking. I need to know it before I actually learn them, just to have a strong imperative. Learning the new way of thinking is a long and hard process, I just want to know what waits for me at the end.

I hope someone who know that reason, will tell me and those who also need it, why it's worth the efford. Thanks in advance.

-- Your Anonymous Coward who wants to learn new ways of thinking...

Apple did an admirable job popularizing some of these ideas and bringing to market a successful product, although in the process, they cut many corners. But Apple neither developed the groundbreaking ideas nor were they even first to market.

IIRC, Xerox originally came up with the concepts of the personal computer, the graphical user interface, the mouse, and several other substantial breakthroughs in computer science.

According to this page, the personal computer was invented in 1949. Xerox was a chemical company called Haloid at the time, and was just getting into the photocopy business.

This very good primer describes how various pieces of the GUI were invented throughout the 50s and 60s by people such as Ivan Sutherland and Alan Kay.

The mouse was invented by Douglas Englebart in the mid-1960s.

Xerox did invent at PARC in the 1970s and beyond: several other substantial breakthroughs in computer science, such as Ethernet and Object-oriented programming.

If you've really only been programming in Lisp for a week or so then you really haven't had time enough to appreciate what its strengths and weaknesses are. It sounds to me as though you have acquired a disease that is all too common amongst programmers - the desire to want to specialise in one language too early on.

I simply cannot emphasise enough how valuable it is to learn as many programming languages as possible. Even if you don't really like it at first, a language can grow on you in ways you would have never imagined. No language is perfect, so knowing a selection of different languages will give you the opportunity to choose a tool that is appropriate to the job in hand. If the only tool you have is a hammer, then every problem you come across starts to look like a nail.

By keeping your horizons broad, most especially by learning languages that might seem strange, counter-intuitive or even downright annoying at first, I can assure you othat you will become a much, much better programmer in the long run. The ways in which languages differ can often give you an insight into the ways that different programmers might solve the same problem.

FWIW, the presence of closures and eval are not the only things that make Lisp distinctive from other languages. The one truly unique (not to mention incredibly powerful) feature of Lisp is macros. You will not be able to find these in Perl. Also, in Perl the standard way to solve problems is with an iterative, procedural style, where Lisp more often employs recursion and an applicative programming style, both of which are techniques well worth the effort to learn about.

Whether Lisp is better than Perl for AI is debatable. I'd argue in favour of Lisp for the following reasons: one is the fact that Lisp is extremely good at knowledge representation (and the subsequent manipulation of that knowledge), but more important is Lisp's ability to generate code with macros, effectively meaning that you can write programs to write other programs. It's also probably worth noting that Lisp is quite a lot faster than Perl, given a decent enough compiler. See The Programming Language Shootout if you don't believe me. Lisp is also a very mature language, with an ANSI standard, so unlike Perl you can be certain that it won't be pulling any carpets out from underneath your feet any time soon.

If I haven't done a enough good job of convincing you that learning Lisp is worthwhile (and I probably haven't) then try checking out Paul Graham's Beating the Averages. Also, be sure to check out Richard Gabriel's Good News, Bad News and How to Win Big. And have a read of Paradigms of Artificial Intelligence Programming by Peter Norvig for some more specific examples of Lisp as an AI programming language. Particularly relevant might be the section in the preface entitled Why Lisp?.

And when you're done with Lisp, I'd recommend a look at Ocaml, SML, Ruby and Smalltalk (particularly the delightful Squeak)!

Woops. That link should be Smalltalk.ORG.

I haven't had a lot of experience with it, but SmallTalk is a great language for learning object-oriented principles, because it is purely object oriented; everything in the language is an object, from integers to windows to text and all methods act on an object. In that respect, it's a bit closer to "human thinking" than most programming languages.

I did not study SmallTalk until my Programming Languages Concepts in my junior year here at Penn State, but I wish I had studied it earlier. My initial reaction to the language was it would make a perfect "introduction to programming" language, particulary object-oriented programming. Squeak is a great implementation of SmallTalk, very intuative design and easy to examine classes, objects, and methods.

T_f_J, you're entitled to an opinion, of course, but your vocabulary in itself demonstrates the problem. To serve the economic and egoistic purposes of various Influential Entities, programming languages have become like car styles and Parisian fashions. Who judges that a programming language "belongs in a by-gone" era? What's the basis for that judgment? Is it that it hasn't a Roy Oily animal character and book assigned it yet? Is it that there's no John Wayne icon picked for it? Surely, a programming language is judged based upon the readiness with which its practitioners can build real systems while keeping an eye on long term costs and adaptability to changes in requirements.

If popularity were the test of achievement, then Visual Basic is (and remains, despite some deflation) king of the hill. You can't really mean that.

Most people who embrace Smalltalk have tried many other languages in professional contexts and are simply compelled to use it. There are lots of reasons why programmers unfamiliar with Smalltalk are missing out, even if they don't or can't use it. It's a powerful idea. I've described some of these in a letter to the editor of Dr Dobbs about a year ago. Smalltalk repeatedly surprises even its afficianados with rediscovered power and grace.

And if you want to see some of the other reasons Smalltalk wins, check out John McIntosh's site, Peter Lount's place, and the nifty (IMO) Dolphin Smalltalk.

I think an excellent OO language to get started is Smalltalk.

And it's used in those situations where other development environments fail to manage complexity.

Alan Kay ('I invented the term Object Oriented') gives a nice demonstration of Squeak Smalltalk from a child's perspective in his famous talk The Computer Revolution Hasn't Happened Yet; spool forward to minute 48 for the Squeak demo.

For Smalltalk info start browsing at www.smalltalk.org.

He's right. Learning some things will definitely help the way you think about things. The incredibly strong typing of something like pascal will definitely kick your *ss if you've been doing nothing but C for a while, and I think that's actually a Good Thing. Learning Eiffel if you already know smalltalk is a very different experience.

Even something like Algol will probably change your views and get you closer to the hardware in many respects (not that you can get Algol to run on most machines anymore....;-)

What about Ada? Programming by Contract really will teach you something serious about how you actually interact with the rest of your application, and while you'll curse it ("I KNOW what I'm trying to do and it's correct, dammit!") you'll be happier for learning it. Older, but happier.

And as long as the languages keep coming, there'll pretty much never be a chance to really run out.

My list would include:

• C
• C++
• Pascal& lt;/a>
• Lisp (anything but eLisp)
• Python
• Perl
• Smalltalk
• ML
• prolog&l t;/a>
• Eiffel
• Ada
• a RISC Assembler
• Cobol (those who do not learn from history are doomed to repeat it)
• Java
• BASIC (the non-Visual kind).

Want an aquatic robot? Check out the MicroSeeker. It's not commercially available, but it seems like it will be someday. What makes this robot interesting is that it runs Smalltalk, as opposed to a crappier language like the variants of C and BASIC most robos run. There's PIC/Smalltalk for the motor control, a Handspring Visor running PocketSmalltalk for high-level control, and the simulator is written in Squeak. A veritable cornacopia of Robotics and Smalltalk.

Java IMHO is a hardcore OO language.

Some have dared go further