I was helping a friend with a C++ lab assignment yesterday. By the time he finished writing up his code, I had; * downloaded a version of Smalltalk (after many false starts) * installed it (I always forget to set $home in VWNC) * written up my methods * written up the support code he'd started with * debugged it Then he tried to run his code and found out he had to allocate memory, that C++ wouldn't accept a 2D array as a ** char, and proceeded to spend the rest of the evening dealing with pointers. Moral of the story? "It would've been faster to learn Smalltalk." Which brings to mind Smalltalk to C/C++ translators. Squeak's Slang translator doesn't seem to be useful for this sort of application? Wouldn't it be of enormous practical advantage to have a generation of C++ students who learned Smalltalk instead of C++? ''Was the friend actually learning C++? I can see almost no reason to create an 2 dimensional array in an object oriented language nor work with double pointers.'' That's why he took the course; to learn C++. He now realizes his mistake. ---- I've had similar experiences, those few times in my undergraduate career when I was actually allowed to choose my language. :) I'm not sure I'd want to try to translate Smalltalk to C++, though. Some Smalltalk concepts (like blocks) are going to be hard to translate. Keyword method names will have to be mangled (which is fine if all you want is running C++ code, but not so good if you want this to be good-looking C++ code). You'll need to figure out where to draw the line between Smalltalk and C++ - if the Smalltalk code uses an OrderedCollection, do you use a C++ vector or do you translate the entire Smalltalk collections hierarchy? You'll need to figure out how to spew the correct type names all over the C++ code. Garbage collection might be a hassle. And you certainly won't be able to translate any of Smalltalk's more dynamic reflective things. But go for it. ;) It might be fun, at least. -- AdamSpitz Nonsense. Write a smalltalk interpreter in C++, and then write the assignment in that :) ''Whatever method you choose, the resulting code should pass the scrutiny of the average instructor or teaching assistant. And also any reprisals from C++ instructors who think that showing initiative is "cheating".'' ''I might do it myself if I didn't have plenty of social engineering projects on my plate already. It would also help if I knew C/C++.'' ---- I'll be out back converting gold to lead. ''The idea here isn't to actually do anything useful. It's all just a con job for Smalltalk. Many Smalltalk fans and industry people whine about the unpopularity of ST, but what do they actually do about it? Their proposed solutions are to talk, and talk, and talk some more. Why not do something concrete and directly address the problem? The problem being how to '''encourage the teaching of Smalltalk in academia at the expense of C++'''.'' Who decided the project should use C++? ''That would be the head of the computer science department. Who only decided to offer a C++ programming course instead of a Smalltalk one because of a combination of 1) inertia / ignorance, 2) anticipated student revolt, 3) market pressure, 4) lack of qualified Smalltalk instructors.'' ---- Begging all of your pardons, and with no malice towards Smalltalk whatsoever... but some of us '''like''' C++. "Killing" it (or any technology) hardly seems desirable (nor practical, for that matter). Maybe "killing" is too strong of a choice of word (thus producing my reaction), "encouraging adaptation of alternate technologies" might be better. And the tandem of Java and DotNet seems to be doing a fine job of replacing C++ in the enterprise as we speak (which will leave the SmugSmalltalkWeenie''''''s with the subsequent problem of how to "kill" Java, I suppose). That said, one still encounters reams of code written in Cobol. Technically, Smalltalk has numerous advantages over C++ in the enterprise; most of its disadvantages are outside the scope of the language definition. (Whether or not they should be considered disadvantages is an open question, though most IT managers seem to think they are). See ArmyOfProgrammers. ''Is this section still relevant in light of the expansion of "kill C++" to "encourage the teaching of Smalltalk in academia at the expense of C++"? Of course, if you deprive IT managers of their army of C++ programmers ....'' ''Before I'm called a language bigot, I should note that I have nothing against weird ass languages just because I can't use them. I have no problem with Lisp, ML, Haskell, Forth, and so on. I also have no problem with languages that still have a function in some highly specialized niche, like assembly, BNF, C. And of course, once Smalltalk dominates the OO scene, it will be time to look at Self and extensions thereof. No, for now it's just C++ and Java that should be targeted for termination.'' ---- Doesn't Smalltalk/X translate Smalltalk into C code? ---- The best way to encourage growth of Smalltalk is to either: * Do something in Smalltalk that lots of people care about, that would not be possible without ST, or * do something in Smalltalk that lots of people care about, that wouldn't be feasible in Java/C++. The ACM Programming competition held in the UK would be a good forum to show off Smalltalk (if it allowed the use of Smalltalk). In a straight competition with the same requirements, you have to solve as many given problems as possible, correctly in the given time. While the C++'ers are pointer juggling, and the Java lot are writing getters and setters, the Smalltalkers (if they're properly trained and gelled), should be shooting far ahead. In a previous job, I was responsbile for writing some code. The management didn't really care how I did it. I hadn't written anything commercially test-first before. Since I believed test-driven development would work well for the code, I wrote the code test-first. At some point, you have to take a leap of faith and start using the thing in which you believe. If you believe something will deliver the best results and you have the power to use it, then why wouldn't you use it? If ST is really that much better (and I believe it is much better than C++/Java for mainstream app development), there must be a way to get demonstrable results that illustrate this. Going the Eiffel "sales through education" route won't help. The kids will only protest that they want to learn C++ to get a job. Employers won't care until they can see competitors beating them because of Smalltalk. At the end of the day you're going to need to motivate people to do Smalltalk in some form. The best way to do this is to prove that it can thrash the competition and then let people decide if they want to continue pointer juggling in C++ and configuring EJBs... -- I hear a lot of people complaining about Smalltalk standardization. I have to wonder; are there any compatibility libraries or apps that let you run or migrate code from one Smalltalk to another? ---- The path I've chosen is to simply '''use''' Smalltalk to solve problems and create value. Let those who want to argue about how great C++ is continue to write their C++. I do things every day in Smalltalk that I shudder to even contemplate in C++ or Java. Someday, another language may come along that improves on Smalltalk, and when it does I'll use it. In the meantime, I have work to do. -- TomStambaugh Yes, that works fine for you. But that's not exactly a political solution, is it? And what happens if your employer decides to foist C++ or Java on you? ''Then you have two choices: 1) Quit, or 2) Use the technology specified by the employer/customer.'' ''Arguments for 1: EverythingIsPolitical; by quitting (or refusing the work) you strike a blow for better technology (assuming that one agrees with the premise that Smalltalk is so much better than C++/Java/etc. that this is a battle worth fighting).'' ''Arguments for 2: It's the employer's dime. If the customer wants to constrain the architecture, and the work remains possible thus constrained - let him/her.'' I think anyone who accepts a TakeItOrLeaveIt stance as valid or legitimate, let alone useful, is incredibly immature. Politics, among other things, is the art of creating alternatives to TakeItOrLeaveIt. ''The TakeItOrLeaveIt above assumes that the customer has given you (the contractor/employee hired to write the software) such a choice - that other alternatives have been proposed and rejected. Nobody is suggesting that at the first mention of Java or C++ from the customer, one should immediately put his foot down and declare MyWayOrTheHighway. Many customers are more interested in the end result, and less interested in the underlying nuts and bolts. But some may insist on doing a project in a particular language - and perhaps for valid (in their eyes) reasons. Contractors need to deal with these folks, and if work is offered on a TakeItOrLeaveIt basis, then you have two choices: TakeItOrLeaveIt.'' ''Of course, TakeItOrLeaveIt is often used as a negotiating tactic; it often doesn't really mean TakeItOrLeaveIt. To discover if that's true, you have to make counter-offers.'' ''And sometimes, you'll end up having to walk anyway.'' TakeItOrLeaveIt isn't immature because there are tactics and methods one can use. It's immature because it's ''individualistic''. All useful politics is collective. Even anarchist politics is collective, just involving voluntary organizations and mutual aid. To focus solely on ''what can I do as an individual to better myself alone'' is to be immature, it is to be, well ... Anglo-American. ---- Yes, that works fine for you. But that's not exactly a political solution, is it? And what happens if your employer decides to foist C++ or Java on you? ''It was precisely because of these sorts of brain-dead choices that chose to never again have an "employer" a decade ago. When my '''customer''' or my '''client''' tells me they want something in C++, I politely suggest that they talk one of the multitude of C++ programmers out there. When my customer or client asks for Java, I explain that it will be MUCH more expensive, slower, and may not work as well. If the customer or client agrees, and is willing to pay the higher price, I decide whether or not I want the work. As the market matures, most of my prospects assure me that they don't care how I solve the problem, so long as it works. -- TomStambaugh'' Yes, that works fine for you. What about the hundreds or thousands of other schmoes left with employers? -- AnonymousDonor ''Apparently they choose to accept their lot as employees. Any of us can go out on our own anytime we choose. For what its worth, it never gets easier than right now. There is never a "good" time, whatever pressures keep someone thinking they need a job today will be just as strong tomorrow. When your employer insists that you do something you know to be stupid, follow the government's advice: "Just say NO." -- TomStambaugh'' I used to want to change the world. Everybody would be so much more productive if they knew the things I know. So I evangelized my favourite language, my favourite methodology, my favourite operating system. It made me crazy, because most people didn't listen. Some did. But to everybody else, I was just an annoyance. I still want to change the world, but now I think that the way to do it is to make myself happy, explain why I'm happy to anybody who asks, and let the people who don't ask find their own way. OnlySayThingsThatCanBeHeard. -- AdamSpitz ---- This page is CategorySoftwarePolitics and it's just amazing how naive people are about politics here. I mean, you got people whose attitude is 'look out for #1'. Then you got people who want to single-handedly change the world and then are surprised (and depressed) when they fail. What the hell were you thinking? If you want to change the world, take a lesson from political movements in history. Do you seriously think that politics in software is somehow magically different just because software is a new field? Well, I got news for you: '''it isn't'''. (This is like the people who are astonished that electronic communities of people act just like normal communities of people with regards to sex talk, leader worship, enemy bashing, et cetera. Excellent paper at http://shirky.com/writings/group_enemy.html) What are the lessons from history? First, don't act individually, act collectively. You will never be able to achieve ''anything'' individually. Second, stop talking, start doing. Talking never achieved anything, except to bore people, do something ''concrete'' that will get you closer to your goal. ''Cool, Dude. When are you going to take your own advice?'' Unfortunately, all one ever sees on wiki is the talk... and as such, you can't tell from wiki alone whether they're actually ''doing'' anything interesting. ---- ''Unfortunately, putting this into a small category and not providing the links below means it is difficult to find except when searching for something else.'' -- JohnFletcher ---- CategorySoftwarePolitics CategorySmalltalk CategoryCpp SmalltalkLanguage CeePlusPlus