Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm working as a COBOL programmer - have a 6 months work experience - for a consulting firm . Today, with the rest the COBOL "department", I had a meeting with the new director of my company.
After an initial analysis made by the new team in charge, they noticed that, comparing to the other services/technologies our company has to offer - Java, C++, Objective-C, etc - COBOL was lacking "advertisement". He stated that whenever members of other teams are in-between projects they implement small demos which then can be shown to our clients whenever there is a presentation of our company. He gave examples of widgets for mobile devices in Objective-C, cool web-pages with HTML5, etc.
And noticed that there is nothing in COBOL like that. So he wants us to develop some kind of tool/app to show what our competences.
We already told him that COBOL is used under the hood, and doesn't have bells and whistles to show. Also that when hiring a COBOL programmer/analyst the most important for the client is that he shows he has "business logic" knowledge.
I know that the coding part is very important but after a two weeks introduction to the mainframe environment and to COBOL I was capable of doing my programming tasks easily. But with a 6 months experience working in a bank I find myself having to, nearly everyday, ask questions regarding "business logic" to the "gurus" just so that I don't end up changing the logic of the process when performing some maintenance task.
Can we really make something (tool/app) that shows or future clients that we have something different to offer than all the other company's which provide the same services? Or if not, is there anything that we can say to our manager so that he understands that COBOL is different from the other languages and it's purpose is not to display pretty graphics on the screen.
Thank you!
I think you're absolutely right - the "curly brace" languages have had a lot of marketing of the brand from IBM , Oracle/Sun and Microsoft over the last 20 years.
Micro Focus is trying to do something about this. They just relaunched www.cobol.com which includes a nice set of video testimonial to the power of COBOL.
There's a great video available showing some of the demos Micro Focus built as part of the development of the soon to be released "Visual COBOL R3" product. These demos include web services, rich browser-based clients, parallel processing and more (they aren't all shown in the video). Micro Focus will shortly be launching new resources for COBOL developers that will include these samples.
COBOL gets a bad rap in large part because there is the conception that it's outdated and unable to communicate with modern systems. A lot of people think that using COBOL "locks you in," unable to get data from other systems, push data to other systems, or call code that's written in other languages.
Potential clients would be very interested to know that, if they went with your COBOL solution, they could still share data with the rest of the world. I think you could build some compelling demos showing COBOL applications interacting with Web APIs or with code written in C++, Objective-C, etc. Two possibilities:
1) A simple program that submits a query to Google's search API and displays the returned results. This will show that you can issue HTTP requests and parse the responses.
2) A program that gathers data from a custom database and passes that data to a C++ function that somehow grinds up the data and returns a result. This will show that you can use COBOL's data handling strength and pass off to C++ or some other language the more processor-intensive calculation tasks that COBOL traditionally has not been as good at.
I think that's your biggest selling point: that you use COBOL for its strengths, that you're able to share data with the rest of the world, and your COBOL programs can leverage other tools for specific tasks that are not COBOL's primary function.
Having a slick demo in your back pocket to show (snow) clients is kind of like
selling sizzle not the steak. Demo applications may illustrate how skillfully your staff
can knock off a relatively light-weight problem with a lot of flair. But COBOL is less about sizzle and
more about the steak - a marketing nightmare if style is emphasized over content.
Basically, a hot demo illustrates to clients that you have some imagination, know how
to write code within a given framework that integrates various services. Undeniably these are all good selling points.
But COBOL applications don't make for great demos. Most clients running large COBOL shops already know this.
It is unlikely they would be impressed by a demo - unless it addressed some specific point of interest
to them. From my 20+ years experience as a contract COBOL
programmer, I can say my clients are mostly interested in a solid resume backed up with solid references that illustrate a
depth of experience in specific application domains (eg. accounting, human resources, inventory management,
and the like).
A solid company portfolio is probably more important than a demo. A few things you might want to outline are:
Type of businesses that you have supplied resources to (banking, finance, government, retail).
Range of technologies, middleware and frameworks employed on given projects (eg. CICS, MQ-Series, DB/2,
WebSphere, FTP, XML, RD/z, SAP, SAS etc.)
Nature of skills provided to past clients (eg. programmers, technical analysts, business analysts, DBA,
capacity planning, security analysts, data modeling, architect, project managers etc.)
Other than "putting bums in seats", point to any added value your company brought to these projects (eg.
found a no-cost optimization that reduced a clients batch schedule by 2 hours).
Put together a project case history to show how your company was able to do something special
and different for a client.
Point to any technologies, frameworks or application domains where you feel your company has some
sort of competitive advantage over the "other guys".
Try to address questions your prospective clients may have about you.
Big COBOL shops have their own way of doing things. They often use a similar set of tools, but they
all seem to have their own peculiar way of integrating them. They don't want some contractor coming in to
rock their boat. But you can impress them by showing that your "guys" bring clear
thinking, solid skills and a strong work ethic into the projects they have participated in.
Above all, make the most of what you have accomplished but never over state or fluff up your
abilities beyond the absolute truth. If a client ever catches a whiff of BS from anything
you present, they will be out the door before you can blink.
This is a late entry, but I had some fun linking OpenCOBOL WORKING-STORAGE data to CERN's ROOT/CINT framework. CINT is a way cool C/C++ interpreter, ROOT is the framework for visual analysis of particle collider and high energy physics datums. Interactive charts and graphs from COBOL working store.
A small example:
OCOBOL >>SOURCE FORMAT IS FIXED
*> ***************************************************************
*> Author: Brian Tiffin
*> Date: 20101119
*> Purpose: Pass arguments to ROOT/CINT invoked subprograms
*> Tectonics: cobc -fimplicit-init -C cobparams.cob
*> ***************************************************************
REPLACE ==ARRAYSIZE== BY ==450==.
identification division.
program-id. cobfloats.
data division.
working-storage section.
01 cnt pic 999.
01 val usage float-short.
01 xes.
02 an-x usage float-short occurs ARRAYSIZE times.
01 yes.
02 an-y usage float-short occurs ARRAYSIZE times.
linkage section.
01 vxes.
02 an-x usage float-short occurs ARRAYSIZE times.
01 vyes.
02 an-y usage float-short occurs ARRAYSIZE times.
*> ***************************************************************
procedure division using by reference vxes, vyes.
perform varying cnt from 1 by 1 until cnt >= ARRAYSIZE
compute val = cnt * function random() end-compute
move cnt to an-x in xes(cnt)
move val to an-y in yes(cnt)
end-perform
move xes to vxes
move yes to vyes
move cnt to return-code
goback.
end program cobfloats.
and a sample run
$ cobc -fimplicit-init -C cobparams.cob
$ vi cobparams.c
(Add a #pragma K&R to the top of cobparams.c so CINT lets up on type safety)
[btiffin#home cobol]$ root -l
root [0] gSystem->Load("/usr/local/lib/libcob.so");
root [1] .L cobparams.c+
root [2] int a = 0; float x[450]; float y[450];
root [3] a = cobfloats(&x, &y);
root [4] a
(int)450
root [5] TGraph *graph1 = new TGraph(450, x, y);
root [6] graph1->Draw("A*");
which produces an interactive graph of some arbitrarily constrained random numbers.
As you are working in a mainframe environment (I presume it's IBM) I suggest you check out the following link http://www-01.ibm.com/software/awdtools/cobol/ to IBM'S COBOL compiler section. There's information there about linking COBOL with web services and Java, in a mainframe environment.
As a previous answer mentioned, you could also look at Visual COBOL from Micro Focus. It's not a mainframe product but is a COBOL complier within Visual Studio and deploying in .NET
http://www.microfocus.com/products/micro-focus-developer/micro-focus-cobol/windows-and-net/micro-focus-visual-cobol.aspx
The kind of situation you may be looking at software for is called rapid prototyping and this involves a program code or script generator to demonstrate the visual appearance of displays or forms to a computer screen and can include some elements of data input and advancing to more screen pages. This is the data processing department type of style and presentation rather than one which has graphics, web access and so on that a programmer of a desk computer or laptop/notebook would probably encounter and use.
I realize this is quite a late entry, but why don't you highlight Cobol at it's strongest -- churning through massive chunks of data while applying business logic and extracting current state.
May I suggest you prepare a nice set of reports on your current database. Extract, detail, summarize, and slice and dice the data a dozen different ways. Make sure you note the runtimes to create the report suite compared to other languages trying to do the same things. And note the readability of the code (and thus, modifiability of the report suite) compared to what other languages might offer.
Extract to a CSV while you are at it and add in some Excel (or other spreadsheet) graphing and data analysis.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
What is COBOL used for?
COmmon Business Oriented Language 'invented' by Grace Murray Hopper ( read about her she is one one of the pivotal people in the development of computing as we know it today). The general idea was to produce a language that was English based as opposed to mathematically based or expressed as such in the code.
Very simply put you would use a construct like
ADD YEARS TO AGE
as opposed to
age = age + years
or
age += years
Appearing in the early 1960's it was massively adopted for processing in the area of business. There are still a large volume of applications built in COBOL still running and maintained and it is still very much alive and kicking. Around 1997 Gartner reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually. So you could do a lot worse than learn COBOL to ensure you have a job for life.
The structure of a cobol program is summarised in the Mnemonic In Every Damn Program. Meaning that there is an:-
Identification Division giving information about the program
Environment Division describing the hardware
Data Division (In my day we used CODASYL now better known and newly re-invented as no-sql
Procedure Division 'Here be code'
Because of the legacy from punch cards (yes i used them as well) you always started the code by indenting 8 spaces in else some compilers would not recognise it (shades of Python where whitespace is significant).
It is of course a compiled language.
Where is it used. Governments, the Military Businesses of all sizes but usually the larger corporates so i suppose you could say everywhere and it is used to run governments, and the Military and business's. I believe the US's social welfare system runs on several million lines of Cobol written in the mid 60's. Experian a large UK based credit rating company uses it throughout there operation with interfaces to the web. Again in the UK most of the Building Societies and Banks run their core systems on it.
I could go on but i won't go and read about it. And by the way you can even get Object Oriented Cobol if you want
Ever use a credit card? Your transaction is probably touching COBOL code on the backend.
The Right Tool for the Right Job
Batch
The most salient point about COBOL is not its verboseness. It is that it was primarily designed, as a language, to do batch processing. Its I/O functionality in that regard is exceptionally efficient.
Even though it predates OOLs by a geological epoch, it is useful when speaking to a modern-day OO programmer to describe batch programming and COBOL from an OO point of view. Describing it like this, though historically incorrect, helps OO programmers conceptually.
To wit, the utterly fallacious, and yet very true:
COBOL has been "optimized" to iterate over large, nay, vast sequential "collections"
(i.e. batches, also known as files). In fact, it is so optimized, that all the OO
functionality has been stripped out, leaving a basic API that opens files, processes
records, and closes files. In more complex version of the basic algorithm, multiple
files are opened, their records matched to each other and manipulated to produce one
or more output files (batches).
Where COBOL was co-opted for non-batch processes, for instance pseudo-conversational programming (backing up CICS "green" screens - aka BMS), it was least suitable. Not surprisingly, it is this functionality that has been most quickly replaced by GUI apps written in OOLs.
The Editor
The ISPF Editor on IBM mainframes has been optimized to handle the kind of coding COBOL requires. The basic unit of manipulation in the editor is the line. By default, vertical alignment is static and not flowed or shifted based on context; typing to the end of a line results in a keyboard lock. Because of this "conservation of vertical alignment," it is relatively easy to duplicate lines or blocks of lines, and align commands. With COBOL vertical alignment, as a legibility issue, is of greater importance than OO languages.
It is difficult to describe in a post, but having facility in both programming worlds and with both types of editors, I have to say that I would not want to edit COBOL in an IDE style editor, and I would not want to edit Java and C-family languages in an ISPF Editor. (I imagine you can plug-in an ISPF style editor into the various IDEs, but I haven't had the need to go there.)
N.B. OO COBOL has its uses, but not as a new way to re-engineer code that handles batch processing.
From my, although limited experience, COBOL is used a lot with IBM mainframe systems. So I believe in any situation where I/O is the emphasis (as mentioned above financial systems, insurance companies, government, etc) to the extent that a mainframe is needed or preferred and has been around for a while COBOL is probably used. I say been around for a while since in modern day I do not hear much of COBOL being a go to language.
Cobol is used primarily for financial processing. Any time banks, brokerage houses, credit card vendors, et al are doign business, there will be Cobol in the mix.
The ANSI standard for COBOL and some compilers have evolved considerably in the last 15 years and include libraries for creating and operating web frame contents and interactive sites, for data communications, for running on small processors and devices used in the hand. Well known versions are prefixed with characters like MF, CIS, RF, RM or the names of computer mainframe manufacturers old and new for versions in use primarily in Data Processing computer installations.
Today COBOL is used only because it used to be popular back in the day, and many old large businesses don't want to re-write their code into a modern language. (mainly cost + time)
The maximum length of a line of COBOL code is 72 characters long, why you ask? Because that's how many holes there were in punch cards. Even still the language hasn't been updated to allow for longer lines...
COBOL is an evil, ancient language that has little use any more, unless you are extending OLD programs...
COBOL is used for Business applications. Fortran is for scientific apps. C and C++ for hardware and firmware. Java for the web.
Then you may ask, why COBOL? Well, COBOL is about ten times easier to program for business than any of the other languages.
For example, to move a numeric to a report field and format it as a currency:
MOVE VAL-A TO REPORT-FIELD-A.
There are no getter or setter methods needed. No need to program two methods for each MOVE statement.
And all the changing to string characters, and formating to $99,999.99 IS automatic. Try that in any of the other languages.
The dirty little secret is that COBOL is really a glorified ASSEMBLER MACRO language. There is even a compiler option to print the assembler code. That makes it easy to understand and powerful.
COBOL: Easy, quick, accurate, readable and maintainable. Everything a boss could ask for.
I have a task to convert COBOL code to .NET. Are there any converters available? I am trying to understand COBOL code in high level. I have a trouble understanding the COBOL code. Is there any flowchart generators? I appreciate any help.
Thank you..
Migrating software systems from one language or operating environment to another is always a challenge. Here are
a few things to consider:
Legacy code tends to be poorly structured as a result of a
long history of quick fixes and problem work-arounds. This really ups the signal-to-noise ratio
when trying to warp your head around what is really going on.
Converting code leads to further "de-structuring"
to compensate for mis-matches between the source and
target implementation platforms. When you start from a poorly structured base (legacy system),
the end result may be totally un-intelligible.
Documentation of the legacy architecture and/or business processes is generally so far out of
date that it is worse than useless, it may actually be misleading.
Complexity of COBOL code is almost always under estimated.
A number of "features" will be promulgated into the converted system that were originally
built to compensate for things that "couldn't be done" at one time (due to smaller memories,
slower computers etc.). Many of these may now be non-issues and you really don't want them.
There are no obvious or straight forward ways to refactor legacy process driven
systems into an equivalent object oriented system (at least not in a meaningful way).
There have been successful projects that migrated COBOL directly into Java. See naca.
However, the end result is only something its mother (or another COBOL programmer) could love, see this discussion
In general I would be suspicious of any product or tool making claims to convert your COBOL legacy
system into anything but another version of COBOL (e.g. COBOL.net). To this end you still
end up with what is essentially a COBOL system. If this approach is acceptable then you
might want to review this white paper from Micro Focus.
IMHO, your best bet for replacing COBOL is to re-engineer your system. If you ever find
a silver bullet to get from where you are to where you want to be - write a book, become
a consultant and make many millions of dollars.
Sorry to have provided such a negative answer, but if you are working with anything
but a trivial legacy system, the problem is going to be anything but trivial to solve.
Note: Don't bother with flowcharting the existing system. Try to get a handle on process input/output and program to program data transformation and flow. You need to understand the business function here, not a specific implementation of it.
Micro Focus and Fujitsu both have COBOL products that work with .NET. Micro Focus allow you to download a product trial, while the Fujitsu NetCOBOL site has a number of articles and case studies.
Micro Focus
http://www.microfocus.com/products/micro-focus-developer/micro-focus-cobol/windows-and-net/micro-focus-visual-cobol.aspx
Fujitsu
http://www.netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview
[Note: I work for Micro Focus]
Hi
Actually, making COBOL applications available on the .NET framework is pretty straightforward (contrary to claim made in one of the earlier responses). Fujitsu and Micro Focus both have COBOL compilers that can create ILASM code for execution in the CLR.
Micro Focus Visual COBOL (http://www.microfocus.com/visualcobol) makes it particularly easy to deploy traditional, procedural COBOL as managed code with full support for COBOL data types, file systems etc. It also includes an updated OO COBOL syntax that takes away a lot of the verbosity & complexity of the syntax to be very easy to write COBOL code based on C# examples. It's unique approach also makes it easy to use all the Visual Studio tools such as IntelliSense.
The original question mentioned "convert" and I would strongly recommend against any approach that requires the source code to be converted to some other language before being used in a .NET environment. The amount of effort and risk involved is highly unlikely to be worth any benefits accrued. On the contrary, keeping the code in COBOL maintains the existing, working code and allows for the option to deploy onto other platforms in the future. For example, how about having a single set of source code and having the option to deploy into .NET as a native language and into a Java environment without changing a line of source code?
I recommend you get a trial copy of Visual COBOL from the link above and see how you can use your existing code in .NET without making any changes.
This is not an easy task. COBOL has fundamental ideas about data types that do not map well with the object-oriented .NET framework (e.g. in COBOL, all data types are represented in terms of fixed-size buffers) and in particular the way groups and arrays work do not map well to .NET classes.
I believe there are COBOL compilers that can actually compile .NET bytecode, but they would have their own runtime libraries to manage all of that. It might be worth looking at one of these compilers and simply leaving the legacy code in COBOL.
Other than that, line-by-line translation is probably not possible. Look at the code at a higher level and translate blocks of code at a time (e.g. at the procedure level or even higher).
There are a lot mechanisms how to convert COBOL to modern scalable environments, such as .NET or Java.
The first is a migration to a new environment with saving the existing COBOL code with some minor modifications (NET Microfocus COBOL);
The second is a migration to a new platform with simulation of COBOL statements and constructions. When there are some additional NET/Java libraries to simulate some specific COBOL logic:
ACCEPT goes to NETLibrary.Accept and so on.
The third approach is the most valuable one, when you migrate to "pure" NET/Java code with all the benefits of the new environment. It can be easily maintained and developed in the future.
However, the unique expertise and toolkits are required for this approach, and there are only a few players on the global market that can help you in this case.
If we are talking about automatic migration, the number of players decreases greatly and, unfortunately for you, you have to pay for the specific technologies and tools (like ours).
However, it is a better idea to invest your money in your future growth in the modern environment, than to spend your money on the "simulation" of old technologies.
Translations is not an easy task. Besides Micro Focus and Fujitsu there is also Raincode that offers a free version of Cobol that nicely integrates with Visual Studio.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Ruby is becoming popular, largely from the influence Ruby on Rails, but it feels like it is currently struggling through its adolescence. There are a lot of similarities between Ruby and Smalltalk -- maglev is a testament to that. Despite having a more unusual syntax, Smalltalk has all (if not more) of the object-oriented beauty of Ruby.
From what I have read, Smalltalk seems to have Ruby beat on:
Maturity (developed in the 1970's)
Stability
Commercial support
Distributed source control (understands structure of code, not just text diffing)
Several implementations of the VM
Cross-platform support
The seaside web framework as a strong alternative to Rails
It seems like Ruby is just reinventing the wheel. So, why don't Ruby developers use SmallTalk? What does Ruby have the Smalltalk doesn't?
For the record: I'm a Ruby guy with little to no experience in Smalltalk, but I'm starting to wonder why.
Edit: I think the ease-of-scripting issue has been addressed by GNU Smalltalk. As I understand it, this allows you to write smalltalk in regular old text files, and you no longer need to be in the Smalltalk IDE. You can then run your scripts with:
gst smalltalk_file
I'm more of a Pythonista than a Ruby user, however the same things hold for Ruby for much the same reasons.
The architecture of Smalltalk is somewhat insular whereas Python and Ruby were built from the ground up to facilitate integration. Smalltalk never really gained a body of hybrid application support in the way that Python and Ruby have, so the concept of 'smalltalk as embedded scripting language' never caught on.As an aside, Java was not the easiest thing to interface with other code bases (JNI is fairly clumsy), but that did not stop it from gaining mindshare. IMO the interfacing argument is significant - ease of embedding hasn't hurt Python - but this argument only holds moderate weight as not all applications require this capability. Also, later versions of Smalltalk did substantially address the insularity.
The class library of most of the main smalltalk implementations (VisualWorks, VisualAge etc.) was large and had reputation for a fairly steep learning curve. Most key functionality in Smalltalk is hidden away somewhere in the class library, even basic stuff like streams and collections. The language paradigm is also something of a culture shock for someone not familiar with it, and the piecemeal view of the program presented by the browser is quite different to what most people were used to.The overall effect is that Smalltalk got a (somewhat deserved) reputation for being difficult to learn; it takes quite a bit of time and effort to become a really proficient Smalltalk programmer. Ruby and Python are much easier to learn and to bring new programmers up to speed with.
Historically, mainstream Smalltalk implementations were quite expensive and needed exotic hardware to run, as can be seen this net.lang.st80 posting from 1983. Windows 3.1, NT and '95 and OS/2 were the first mass market operating systems on mainstream hardware capable of supporting a Smalltalk implementation with decent native system integration. Previously, Mac or workstation hardware were the cheapest platforms capable of running Smalltalk effectively. Some implementations (particularly Digitalk) supported PC operating systems quite well and did succeed in gaining some traction.However, OS/2 was never that successful and Windows did not achieve mainstream acceptance until the mid 1990s. Unfortunately this coincided with the rise of the Web as a platform and a large marketing push behind Java. Java grabbed most of the mindshare in the latter part of the 1990s, rendering Smalltalk a bit of an also-ran.
Ruby and Python work in a more conventional toolchain and are not tightly coupled to a specific development environment. While the Smalltalk IDEs I have used are nice enough I use PythonWin for Python development largely because it has a nice editor with syntax highlighting and doesn't get underfoot.However, Smalltalk is was designed to be used with an IDE (in fact, Smalltalk was the original graphical IDE) and still has some nice features not replicated by other systems. Testing code with highlight and 'Show it' is still a very nice feature that I have never seen in a Python IDE, although I can't speak for Ruby.
Smalltalk was somewhat late coming to the web application party. Early efforts such as VisualWave were never terribly successful and it was not until Seaside came out that a decent web framework got acceptance in Smalltalk circles. In the meantime Java EE has had a complete acceptance lifecycle starting with raving fanboys promoting it and finally getting bored and moving onto Ruby ;-}Ironically, Seaside is starting to get a bit of mindshare among the cognoscenti so we may find that Smalltalk rides that cycle back into popularity.
Having said that, Smalltalk is a very nice system once you've worked out how to drive it.
When I leave my house in the morning to go to work, I often struggle with the decision to make a left or right turn out of my drive way (I live in the middle of a street). Either way will get me to my destination. One way leads me to the highway which, depending on traffic, will probably get me to the office the quickest. I get to drive very fast for at least part of the way and I have a good chance of seeing a pretty girl or two on their way to work :-)
The other way allows me to travel down a very enchanting, windy back road with complete tree cover. That path is quite enjoyable and of the two approaches is definitely the more fun, though it means that I will get to the office later than I would have had I taken the highway. Each way has its merits. On days that I am in a big hurry, I will usually take the highway though I may run into traffic and I also increase my chances of getting into an accident (if I am not careful in my haste). Other days I may choose the woody path and be driving along, enjoying the scenery and realize that I am running late. I may try to speed up, raising my chances of getting a ticket or causing an accident myself.
Neither way is better than the other. They each have their benefits and risks, and each will get me to my goal.
I think your question is somewhat missing the point.
You shouldn't choose, you should learn them both!
If you truly are in a position that you can choose the next framework(vm, infrastructure) then you need to decided what to use and can ask a specific question with pros and cons from the perspective of what your application is inteded to do.
I have used smalltalk (love it) and ruby (love it).
At home or for open source project I can use every language I like, but when doing work I have to adopt.
I started to use ruby (at work) because we needed some scripting language that behaved more-or-less equally under solaris,linux and windows(98,2000,xp). Ruby was at that time unknown to average-joe and there didn't exist any rails. But it was easy to sell to everyone involved.
(Why not python? the truth ? I once spend a week hunting for a bug that happened when a terminal converted my space to a tab and the intending got messed up).
So people started to code more and more in ruby because it was so relaxing, enjoying and not a cloud on the sky.
Paul Graham sums it up
It's true, certainly, that most people don't choose programming languages simply based on their merits. Most programmers are told what language to use by someone else.
and
To be attractive to hackers, a
language must be good for writing the
kinds of programs they want to write.
And that means, perhaps surprisingly,
that it has to be good for writing
throwaway programs.
And when were at the Lisp land try to replace LISP with smalltalk
Ruby’s libraries, community, and momentum are good
So if LISP is still more powerful than
Ruby, why not use LISP? The typical
objections to programming in LISP are:
There aren’t enough libraries.
We can’t hire LISP programmers.
LISP has gone nowhere in the past 20 years.
These aren’t overwhelming objections,
but they’re certainly worth
considering.
and
Now, given a choice between a powerful
language, and popular language, it may
make excellent sense to pick the
powerful one. But if the difference in
power is minor, being popular has all
sorts of nice advantages. In 2005, I’d
think long and hard before choosing
LISP over Ruby. I’d probably only do
it if I needed optimized code, or
macros which acted as full-fledged
compilers.
I would say the opposite: Smalltalk syntax is one of the simplest and powerful programming language syntaxes.
It's true the languages are very much alike. The shallow way to interpret that is to call Ruby a Smalltalk cover band. The more reasonable interpretation is that Smalltalk's closed system isolated it, while Ruby's participation in the Unix ecology and habit of appropriating features from every language under the sun gives it an infinitely gentler adoption curve and effortless integration with kickass tools like Git.
Giles Bowkett
Guess who said this? (quote is close, maybe not exact): "I always thought Smalltalk would beat Java. I just didn't know if would be called 'Ruby' when it did so."
Drum roll ....
...
The answer is ... Kent Beck
Stephane Ducasse has some great Smalltalk books available here:
http://stephane.ducasse.free.fr/FreeBooks.html
so although the Smalltalk community is not as prolific as the Ruby and Rails communities, there is still some great help out there.
what does Ruby have that Smalltalk doesn't?
Massive, current support by major platforms (IronRuby and jRuby) that enrich the set of libraries
Evangelists like Dave Thomas who, for years, have been touring around the country preaching the gospel of their language. I have seen Dave at Java conferences stating he doesn't know Java and that he prefers Ruby.
Strong, current real estate on the bookshelves
The creator of Ruby has said that he thinks about the programmer: Ruby's syntax seems to have this Zen appeal. It is hard to pin down, yet seems to galvanize the fans.
Creative, dynamic presentations like Giles and this one that gain mindshare
I think your point is well-taken. As a friend once put it, Ruby might be "old wine in a new bottle" vis-a-vis Smalltalk. But sometimes the new bottle matters. A wine has to be in the right place at the right time.
Beats me. I spent a year checking out Ruby and doing some smallish projects to see how I liked it. I guess I'm a Smalltalk bigot because every time I'd sit down to work with Ruby I'd sigh and think "I'd really rather be doing this in Smalltalk". Finally I gave in and went back to Smalltalk. Now I'm happier. Happier is gooder.
Which of course begs the question, "Why?". In no particular order:
Because the IDE blows away anything else I've ever worked with. This includes a bunch of platforms from ISPF on IBM mainframes to Microsoft's Visual (.*), include things such as Visual Basic 4-6, Visual C++ (various incarnations), Borland's Turbo Pascal and descendants (e.g. Delphi), and stuff on DEC machines in both character mode and under X-Windows.
Because the image is a beautiful place to live. I can find what I want in there. If I can't figure out how to do something I know that somewhere in the image is an example of what I'm trying to do - all I have to do is hunt until I find it. And it's self-documenting - if you want to see the details of how something works you just open a browser on the class you're interested in, look at the method, and that's how it works. (OK, eventually you'll hit something that calls a primitive, and then it's "here there be dragons", but it's usually understandable from context). It's possible to do similar things in Ruby/C++/C, but it's not as easy. Easy is better.
The language is minimal and consistent. Three kinds of messages - unary, binary, and keyword. That describes the priority of execution, too - unary messages first, then binary messages, then keyword messages. Use parentheses to help things out. Dang little syntax, really - it's all done with message sends. (OK, assignment isn't a message send, it's an operator. So's the 'return' operator (^). Blocks are enclosed by square brace pairs ([ ] ). Might be one or two other 'magic' bits in there, but darn little...).
Blocks. Yeah, I know, they're there in Ruby (and others), but dang it, you literally can't program in Smalltalk without using them. You're forced to learn how to use them. Sometimes being forced is good.
Object-oriented programming without compromise - or alternatives, for that matter. You can't pretend that you're "doing objects" while still doing the same old thing.
Because it will stretch your brain. The comfortable constructs we've all gotten used to (if-then-else, do-while, for( ; ; ), etc) are no longer there so you have to Learn Something New. There are equivalents to all the above (and more), but you're going to have to learn to think differently. Differently is good.
On the other hand this may just be the ramblings of a guy who's been programming since the days when mainframes ruled the earth, we had to walk five miles to work through blinding snowstorms, uphill both ways, and computers used donuts for memory. I've got nothing against Ruby/Java/C/C++/, they're all useful in context, but give me Smalltalk or give me...well, maybe I should learn Lisp or Scheme or... :-)
Smalltalk:
people forwards ifTrue: [think] ifFalse: [not thinking]
Ruby:
people think forwards unless thinking backwards
1) Smalltalk's RPN-like control flow by messages is like Lisp - it's regular and cool but weirds people out.
2) Ruby lets people write code using the idiomatic way people speak - do blah unless there's a reason not to.
update rewrote the Smalltalk sample to actually be more legal code..
Ruby is the current buzz language. It's easier to market software built with it right now than a language developed in the 70s.
Community! Ruby and especially Rails has such a great community. When messing around with smalltalk it seemed that there were not as many screen casts, articles, blog posts, etc. written about Smalltalk.
You answered the question in your first line: "Ruby is becoming popular"
There are a lot of interesting modules, projects and such based around Ruby.
If you have trouble doing something in Ruby, it will be trivial to find help somewhere.
Ruby is installed on a lot of computers now (It's included by default on OS X, many Linux distros, and there are good installers for Windows) - I've not seen smalltalk installed by default on any machine I've used..
I would say wether or not one language is superior to another is irrelevant.. As an example, PHP may not be the "best" language ever, but I would still consider using it over Ruby on Rails (a "better" tool for creating websites) because it is so widespread.
Basically, specific pros and cons of a language are far less important than everything surrounding it - namely the community.
Ruby (or any other language) is more popular than Smalltalk (or any other language) because we live in a chaotic universe. To wit:
From Dave Thomas himself, "[after
the] video on 'How to Build a Blog in
Ten Minutes'... Ruby went from being
a nice little niche language, to
being 'a language you wrote Rails
apps in'" (Ruby Conference 2010
keynote).
Early Smalltalk vendors charged prohibitively
Smalltalk, because it was invented (ahead of its time) 30 years ago, occurs to many as an old, "dead" language (like FORTRAN)
corporations consider Smalltalk such a competitive advantage that they hide its use
While the languages are similar in OO features, Smalltalk's killer advantage is the live, open environment (the much-misunderstood 'image'). After you check out this example of programming in Smalltalk, the debate is over.
For me its not so much a case of what Ruby has, but what Ruby hasn't. And the thing that it doesn't have is the need for a VM and complete environment.
Smalltalk is great - its where I learnt OO concepts, but for ease of use I go for Ruby. I can write Ruby code in my favourite editor and run it form the command line.
So, for me, thats what I choose Ruby over Smalltalk.
I think everyone who has been working with Ruby for a while recognizes its deep debt to Smalltalk. As one of these people, what do I like about Ruby over Smalltalk? I think from a strictly language perspective, it's the sugar. Ruby is deliberately a very syntax-sugary language, whereas Smalltalk is a very syntax-minimal language. Ruby is essentially the Smalltalk object model with Perlish syntax sugar. I happen to like the sugar and find it makes programming more fun.
You can find a job pretty easily doing Ruby. Although I really love Smalltalk, it's virtually impossible to get into the Smalltalk niche. There is work around in it, but if you didn't get in when it was popular it's virtually impossible now.
All the other reasons pale into insignificance because you need to spend plenty of time, focused on real work to learn a language properly. If you're not independently wealthy, the best way to do that is exposure to it at work.
Because Smalltalk distributions were priced in multiples of $1000USD whereas Ruby is free.
Ruby is to Smalltalk as Arabic numerals are to Roman numerals. Same math, easier syntax.
I've done a little Smalltalk - the IDE is one thing I remember - does Ruby have good IDE support?
Use Ruby because it has might have business legs, Smalltalk doesn't.
I can tell you from personal experience. Still using Smalltalk, love it, and have used a couple flavors. Although Smalltalk is a great language, and is everything you mentioned, you wont likely convince the average CIO/CTO to use Smalltalk on a new project. Of course, you might even have a hard time convincing a conservative CIO/CTO to use Ruby. In the end you have to be very careful if you want sustained long term commercial support and the ability to find off-the-street employees that can support your systems in the future. As an example, Smalltalk was a really big thing in the early 90's and IBM invested heavily into it in the late 90's. For IBM Smalltalk was going to be the next language for all business applications. IBM put Smalltalk on everything including their mainframe systems. Java became popular, took over the market, and Smalltalk became a niche player. Over a year ago IBM dumped the language (their term is sunset). Also, take a look at the History. ParkPlace and Digitalk where the first major commercial players in the Smalltalk arena, they merged and then went out of business.
I love both Smalltalk and Ruby - but have found that Ruby is more applicable to what I do daily, and is closer to my heart (practically speaking). What does Ruby offer that Smalltalk doesn't?
Text-based scripting
Low implementation requirements (runs in more places)
Easier to learn and justify (Perl and Python programmers will have no trouble
Easier to move programs around - text files!
Interfaces well with native environment
Anywhere Java runs, jRuby runs...
Bigger and much more active community
Some have mentioned gst (GNU Smalltalk); the problems still hold.
Use whatever makes you more powerful and faster to beat your challenge.
For us, a little in house framework, we built in top of seaside is really our superpower.
I love the RoR community, it has the right attitude. That's very very valuable. But at the same time, technologically, seaside makes you stronger against more complicated problems.
You can do great seaside web apps using open-source stuff.
dabbledb was a sartup based on seaside and, hey! Avi sold it to twitter in june this year!
I say you don't need to wait for others to approve your initiative.
Just go for it. Make it done. Show us that works.
You're not alone. We are on the same boat.
Interesting perspective from Robert Martin (from RailsConf 2009): "What Killed Smalltalk Could Kill Ruby, Too"
I think part of the problem is the development-environment-is-the-runtime. This gives a lot of power, but it also presents a larger learning curve.
Here is a hello world tutorial.
This is very different from other languages where I just need to know how to open a text editor and copy and paste text, hit save, and run a compiler. I HAVE to know how to use the environment. That tutorial doesn't even show me how to create a basic program (which is likely more a fault of that tutorial) that I can run.
There is definately a higher cost of just getting things going than most other languages.
Most languages have some nice eye-catching code that they can show off. I haven't seen that with Smalltalk. I also think that there is some stigma to Smalltalk because it has been around so long and it is still relatively obscure.
I think the BIGGEST difference is that Ruby is much more similar to perl in terms of USEAGE. Smalltalk never got a foothold into the "scripting" languages.
The VM is really cool and I hope ruby will have something similar to it so we can treat everything on our OS that is written in ruby as object in memory space, however until then I simply enjoy Ruby's terse, short syntax, the ability to just write a tiny script and reuse it later. Ruby got all the advantages of perl and the OOP is much more similar to smalltalk than perl's OOP hack.
I would go further than Jonke's answer, and say there are now a large number of languages that have a very strong community, almost enough to suit every taste, and a subset of these have mainstream recognition (i.e. your manager will let you use them at work as well).
It's easy to learn the basics of a language, but to actually use it effectively you need to invest enough time to learn the platform and the tools, as well as the syntax and the idioms. IIRC, McConnell claims that it takes about three years to become truly proficient.
Given those things, it's hard to justify spending a lot of time on languages like LISP and Smalltalk, although they are interesting and perhaps educational to look at.
As a latecomer to discussion, the main problem with Smalltalk and Lisp is that you can't run them with CGI or FastCGI on shared hosting.
The unwashed masses are never going to use them if they need VPS or dedicated servers to use them. IMHO Seaside is superior to almost anything out ther, but will it run on Dreamhost or Webfaction?