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.
Related
I like to come in touch with compiling and debugging for the COBOL language. What components and independencies are there, for a working near-real-life-as-possible environment?
Is it possible, in a Win32 environment? Or a modern Intel architecture? If so, are there
specific bootup, operating system or hardware needed, what more / any?
I was looked at IBM z/OS which not looks like something for 'kids' that aim against a future of full-scale business environment. It also appears to be for z/ architecture processors, nothing you bring "home and start with" like it would with SCALA, Ruby, Haskell and such.
Most of my Google-time give light over OpenCOBOL, MX Cobol plus some
more sibblings. I haven't tried those and not sure that they apply what I search for.
When I read about those, looking at the problematic that users are commenting, reading the environment FAQ, those software-packets looks like some kind of Sandboxes that make COBOL but with a little "extra extra". There even exist VS .NET implementations of COBOL and GUI's for the development environment! That's why i don't tag OpenCobol and NetCobol.
I looking further a simple "hello world", "array[0..10]", "obj = new objectY" "y | y == false" (language intro of course begin with syntax). The purpose is to came in touch with common business tasks, which have purposes. I.e. read in/out data files, create and use connection against MSSQL, take inputs from a executing software or script and such.
OpenCOBOL is probably your best best for learning as an intro or a hobby. It's FOSS and reasonably well supported. Grab a redbook or an online tutorial and go to it.
Everything else is going to cost you money. Fujitsu COBOL is probably the most commonly used COBOL on x86 processors, at least in my experience but it's not cheap.
You're right that a z/OS implementation is not super easy. It generally is run on a mainframe. However, COBOL is also most frequently found in this same environment. There are emulators for z/OS out there, but I don't think they're legal. IBM is pretty strict on copyright.
Hmmm, some simple samples:
"Hello World"
Display "Hello World"
"array[0..10]" (lets assume of int)
01 My-Array-Area.
02 My-Array occurs 11 pic s9(8) binary.
"obj - new objectY" (assume obj is declared as object reference)
Invoke objectY new returning obj
"x | y == false" ("y" a relational condition would have to be named differently from "y" a variable unless you did group qualification, so I changed one to x)
if (x or (y = false))
...do stuff...
else
...do other stuff...
end-if
Our company has been developing in Cobol for over 25 years. We are still writing new code every day. Our system contains about 4 million lines of modularised Cobol code and is used by many organisations in New Zealand and Australia.
We started using the Ryan-McFarlane (RM) Cobol but switched to AcuCorp's AcuCobol about 20 years ago. They were bought out by Micro-Focus a couple of years ago, but the AcuCobol stuff is still there as "Extend". This is a truly modern Cobol that can inter-operate with Java, does client-server, is multi-threaded, can provide web-services, etc. etc. and it is also very platform-independent. You can use this Cobol on any current Windows version, dozens of Unix flavours (including many versions of Linux), as well as the old mainframe platforms. It also is a brilliant example of the "compile once, run everywhere" paradigm, as we only compile our programs on one machine, but the software runs exactly the same way on many different platforms (Linux, Solaris, AIX, HP/UX, etc.)
I believe you can download a 30-day evaluation version of the Extend compiler/runtime.
By the way, I have no connection with Micro-Focus except as a satisfied customer.
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.
I've always been interested in writing and designing programming languages. Of course, it's pretty difficult to find an employer that will let you write a programming language as part of your job. So I'm looking for the "next best thing".
What fields of programming will let me get some experience solving some related problems? Or what kinds of employers are most likely to view all of my dinky little interpreters as relevant experience?
If your interest in language design is irrepressible, get a Ph.D. and make it your area of research. You can count on academia to support all manner of unprofitable activity.
None. The bulk of the professionals in that field do not design languages for a living, but retarget existing compilers to new (usually embedded) targets, or work on source2source conversion systems for legacy code, making a few language extensions in the process.
You should really ask yourself if you want this, because, besides from an extremely lucky shot, that is the realistic outlook of what you will do if you go into this industry.
Remember that the big public toolchain industry is not very profitable at the moment, and that maybe a good 100 languages are in largescale pulbic use and continually maintained, after 30 years of programming languages creation.
I know this is is very gloom, but I hope it sets you on the path to chuck the romantic, hobbyist view, and start researching how the real world in this field looks like.
Moreover, having done small hobby projects on your own is not really a pre. You need to show that you can work on large projects in a team, more than that you can create a small interpreter on your own. If you really want to pursue this, I'd recommend:
stay in school, and get a bachelor (preferably a master or PHD) in CS.
join some opensource team that works on a significant project in the field. gcc, but also the Java world, Tracemonkey (Mozilla), Mono etc. Verifiable experience in real world scenarios is very important.
I think the best way to get into this type of work would be to undertake an advanced degree with a specific focus on language design, compilers etc. It's going to be very tough for you to walk in off the street into a private company and start writing new language features otherwise.
You could also shoot a little higher and on your own, or with a small team, produce something that is much more than just a dinky little interpreter. Show your potential employer that you can produce something useful.
I have worked as an embedded programmer for the past ten years. Before that I wrote compilers (and assemblers, linkers, debuggers, etc.) for 20 years.
My co-workers joke that I turn every problem in to a parsing problem. And they're right. I've used techniques that are appropriate for language design many times during the course of my career.
Today, I play around with compiler stuff on the side: http://ellcc.org. It helps me scratch my language itch.
Actually, there is a fair bit of work going on with visual programming. It isn't exactly traditional programming language work as we know it but there is a need for it. For example, a lot of advanced data analysis tools rely on visual programming tools (Pentaho). You don't have to look too hard to find good practical uses of visual programming.
To get into visual programming languages, you will need to do an advanced degree with an advisor in the area. You will need to do some human computer interaction / interface work in addition to the programming language stuff.
An employer that has a rich "domain" (i.e. a complex industry) can benefit from a "domain specific language".
Will they realise this? Unlikely. They'll be too likely trapped in their deep domain (and entrenched legacy systems) to see that a targeted language could help unclog the mire.
But if you bury yourself in a complex industry for long enough to gain rich domain knowledge you may then be able to turn them with your own skunkwork DSL. Slim chance.
Stay in academia. If you want to develop a new language your chances of being paid to do so are vanishingly small. Newer languages tend to be expressions of a novel problem domain, and you only really encounter the chance to develop them where (a) novel problems are part of the scenery, and (b) no-one is troubled by the necessity to actually earn a living.
Please take your time over it, as well. Speaking as a jobbing developer, the last thing I need is another blasted language to learn :-)
In static analysis there is a lot to do, and the problems that come up are related to those that interest you.
Most currently popular languages came out of a geniune NEED to scratch a particular ITCH. Python came about because some non-C programmers NEEDed to customize inputs their C programs and libraries. Lua came out of the NEED to embed a scripting language in to C programs. Erlang was created to address the NEED of 99.9999999% uptime, hot code loading, and highly concurrent execution. Perl came out of the NEED to easily write programs that parsed text files.
So the very simple question any employer will be asking themselves, and you should ask yourself is. What NEED can I supply a solution to that doesn't exist. Hobby work very seldom shows that you are providing solutions to a NEED, most of the time it is showing that you like to re-invent the wheel for the sake of re-inventing the wheel.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have found a software development system which is currently free to use and develop with.
This system is completely codeless and one can develop business oriented applications effortlessly using its GUI and a bit of MDA. The site is : http://www.codeless.com/
But unfortunately it is in Dutch language.
I would like to know if anyone has ever used this product ?
How efficient is this approach and product?
Can one develop codeless applications?
I have looked at the site but the story is extremely vague.
For majority of non-Dutch speakers, I have translated the following text:
Klaar voor de toekomst!
Stel dat u over 20 jaar nog steeds
dezelfde software zou kunnen gebruiken
als nu. Toekomstmuziek? Nou, welkom in
uw toekomst dan. Want Codeless
Technology ontwikkelt software zonder
code die simpelweg niet veroudert.
Door ´reverse enginering´ kunnen wij u
laten zien hoe uw software-pakket er
in Codeless uit komt te zien. En door
gebruik te maken van interfaces,
kunnen we bepaalde delen van uw
systeem vervangen zonder dat er een
Big Bang implementatie noodzakelijk
is.
Wij hebben een manier gevonden om onze
software voor altijd mee te laten
gaan. Omdat we het simpelweg zonde van
uw tijd vinden om telkens opnieuw uw
bedrijfsprocessen te moeten uitleggen
aan een nieuwe ICT-leverancier.
Uw systeem is perfect aangesloten op
uw bedrijfsprocessen. En dat terwijl u
de nieuwste technologieën snel en
voordelig in kunt zetten om zo
concurrentievoordeel te behalen.
Natuurlijk moet u updaten. Maar met de
software die u nu door ons laat
bouwen, bent u gegarandeerd klaar voor
de toekomst!
That translates to:
Ready for the future!
Imagine you are using the same
software in 20 years. Impossible? No,
welcome to your future. Because
Codeless Technology creates software
without code that does not age.
By 'reverse enginering' we show you
your software in Codeless. By using
interfaces, we can replace certain
pieces of your system without the need
for a Big Bang implementation.
We have found a way to let our
software last for ever because we
think it is a waste of your time to
explain your business processes to
your ICT supplier again and again.
Your system is perfectly connected to
your business processes. And still you
are able to use the newest
technologies quick and easy so you
have an advantage on your competitors.
Of course, you still have the need for
updates. But with our software, you
are guaranteed future ready.
It looks like they have developed a product that uses an existing system and creates a new one using the old system as guide. Without the need to write code. This looks great, but I have serious doubts.
My first question: if they are so excellent, why is their site not in English?
I'm not familiar with this specific product, but I have some familiarity with the "theory" (such as it is) of codeless development.
The primitives of programming languages are there for a reason. So there is a tendency for "codeless" or "mouse-based" development systems to gradually accumulate features that correspond to the primitives of programming languages: something similar to function calls (for reuse of pieces of a design), references to parameters within functions, things that loop, conditional branching, things that aggregate several actions into a single action, things that do arithmetic or string operations, etc. By which point they end up with the same issues as all development systems, which all derive from the tendency of users to push the envelope in looking for ever more complex problems to solve. So then they need refactoring and other nice IDE-style features to help them manage the complexity - by which time the "codeless" distinction is more to do with marketing than actual user experience.
We even see this tendency in many attempts to "start again" with a new set of primitives in a text-source programming language. Haskell does not truly eliminate procedural, stateful coding. It has a way of mimicking such capabilities that tastes pretty authentic - because if it didn't, users would try to simulate it themselves and get it wrong.
I've done some reading on their site.
It seems to me that they build software for you, which they claim you can expand effortlessly. I don't see that they claim you can use their software te build your own software without using code. Their concept in their words:
Maatwerksoftware, die nooit veroudert, die u zelf kunt onderhouden én uitbreiden en die bovendien wordt gemaakt waar u bij staat.
That is:
Software built to your requirements, that never ages, that you can maintain yourself, and that on top of that is made while you're watching.
I conclude that they build it, not you.
I've used the visual development tool of the C Control microcontroller. Although it was possible to use almost every feature of the underlying language (BASIC) it found it to be a waste of time. "Mouse coding" simple loops took way longer than just writing the plain BASIC code.
During my first steps into coding and development I tried other products, (mostly game creators) but they always either lack the features normally available in a coded language or are very slow to work with.
But during the last years I noticed an increase of people who are no longer willing to read (natural) text which they cannot understand the first time they read it. Just a single subordinate clause and they don't want to continue.
So I guess there is a market for these kind of codeless development tools, since you can easily get results and the learning curve is much lower. Most tools I used where pretty self-explanatory.
IMHO codeless development enviroments are best suited for
beginners
people who don't want to learn coding
This approach looks great, worth a consideration. Even though it's still at an experimental stage: http://subtextual.org/subtext2.html
The results of "codeless" or "graphical" systems that I've seen always end up not reducing real complexity, with the drawbacks of no collaborative effort, cant diff/patch, can't do a version compare, difficult to put in source control, etc.
In short, just not a well thought-out.
I'll bet that they don't scale well to large data sets either.
I have tested version 1 current version is 2. but as there is not documentation available in English I am a bit baffled as to how we can go ahead building our apps as per our requirements.
The samples provided looked impressive though.
Just my two cents, the idea behind codeless development is not only for beginners/people who don't want to learn coding, but also can be used to teach younger children programming, and utilize it as a storytelling medium.
I am,of course,referring to Alice.
It has it's market, but I don't forsee it taking over traditional programming (eg. typing on the keyboard) due to it's clunkiness.
The appropriate stance with these sort of products is extreme scepticism. I distinctly remember this...
The Last One
Which was a product, released in 1981(!) which claimed to make programmers redundant by generating commercial applications codelessly.
That said, I am currently using a codeless development environment - Wirefusion - for generating 3D interactive java applets. It's extremely good, but it's targeted at a very well defined domain and even there has some issues.
There was Borland's ObectVision in the late '80s.
You can download a copy from an abandonware site.
Something like Scratch or Lego MindStorms is what comes to mind when thinking about codeless software. But this seems like helping someone to code instead of being 100% codeless. And I think that is the way it will have to work in order not to be so limiting. Over time, like all languages/APIs it will improve and more and more people will come out with their own buckets of coding blocks to make it more versatile. No matter what happens though I would always like a way to tweak all generated code, much like a WYSIWYG HTML editor. It will be difficult at first but will only get better with time. But no matter what, coding by hand will always reign supreme.
Replying to the post of geocar..(cant reply anymore to my own post)
To say what the differences are with other I4GL is hard since i dont know all the tools out there, but let me put it this way. If one compares Codeless to MS CRM 4.0 and Microsoft M, what would you think are the differences with I4GL tools?
The proof is in the pudding; I don’t understand why this Bernard deleted who we are. If Charles Simonyi the Billionaire ex-Microsoft guru who has been trying to do the same for 15 years would comment here, would he be deleted?
David Roth, Chief Visionary, Simparel, Inc.
David.Roth at Simparel dot com.
My boss has a good way to generate apps without his having to write code. He has an automatic programmer (me) write it for him. He uses domain-specific language, and gets a working app. Anything that does the same job would have to be about as smart (or dumb) as that.
When requirements are communicated, a language of symbols is used, whether it is keyboard clicks, mouse clicks, or any other form of input.
If a language maps well onto user concepts and allows very little room for misinterpretation or inconsistencies, then it is a good domain-specific-language.
It is good to try to find better domain-specific-languages.It is bad to try to sell one if you don't have one.
So I guess there is a market for these
kind of codeless development tools,
since you can easily get results and
the learning curve is much lower. Most
tools I used where pretty
self-explanatory.
IMHO codeless development enviroments
are best suited for
beginners people who don't want to
learn coding
That is exactly true - and what is accomplished by the neatComponents codeless development platform.
Have a look at www.clearString.com which is targeted at those users
David
Encanvas is completely codeless. It was originally created back in the day to author enterprise-grade situational applications but in the last decade has been used to build anything from spreadsheet replacement type apps to regional traffic systems, business intelligence platforms and eLearning applications.
encanvas doesn't come cheap. It's engineered to enable IT teams to move away from coding and comes with all of the tools you'd expect including cloud deployment.
encanvas is built on .net.