Perhaps Haskell is more elegant, but you must agree
that OCaml is a very good blend of expresiveness,
speed, powerfull libraries and efficient implementation. It is the apropriate language for
those C/C++ Java Perl and Python programmers that are searching for a more powerfull language.
Yes you are right. It is silly assume that in the
real worl all programmers are gurus. But it has
sence that there are better languages and poorer
languages and that means expresiveness, CPU &
memory perfomance, training curve, support libs.
reliability, productivity, maintenace... finally
$$$ that make a significant difference.
Switching to OCaml perhaps is not as expensive as
you think. It is by far more harder recycle a C/C++
programmer as they are get used to deal at very low
level. My experience with VFP programmers is about
to 3 month (45 min/day) to get a productive OCaml
programmer. In the long term it is possible to
achieve BIG savings. I do not recommend to port
graphics apps but non-grapichs as services indeed
yes.
Tim you are right, a good programmer is much more
productive than a bad programmer, but a good C/C++
programmer vs a good OCaml (ML, Clean, Haskell...)
programmer the former will NEVER achieve the productivity of the later. I have a record with more
than 3 years of C/C++ programming and 1 year in OCaml that shows me this fact. By the way C/C++ are
really bad toys compared with OCaml or ML's.
Type Inference checks for you at compile time that
your programm (variables) are coherent so none or
minimal annotations are needed (which is a nice
feature to avoid massive debuging). The type
system has a solid foundational theory as opposed
with C/C++ Pascal... which have flawed type systems
(or how a type system can do an awfull job).
YES YES YES, OCaml is the nicer language I ever
found. It is quite expresive and readable in terms
of the solution (not dealing with stupid
annotations and castings to get cheated elsewhere)
It has being proved to me as I have some measures that OCaml is about 3-5 times more productive than
C++ and debbuging is almost unneeded.
You forgot to say that OCaml has TYPE INFERENCE, a
true professional type system and a great MODULE
system. My experience with OCaml is the best and as a programming language I've put it over Python,
Java, Pascal or C/C++. Functional paradigm is far
better to imperative style. Choosing the correct
programming language MATTERS.
C++ has never being a great language:
1) It's type system is a failure (same as pascal), incoherent and misconcepted design. Real and usefull type systems can be found in ML languages that can found almost errors at compiling stage. C++ and a lot of others are really UNSAFE programming languages.
2) No Garbage Colector. (more memory mistakes)
3) Bloated and useless declarations and syntax. Most C++ programmers only use a subset of the language.
4) Too low level (as Java and pascal) to be reliable in large proyects.
5) Low productivity, a large debugging and testing effort.
6) Low level of expresiveness and abstraction. The programmer waste a lot of time dealing with irrelevant stuffs.
My conclusion:
It is very difficult to C++ to evolve to a BIG language as the basement is poor. Also in the OO arena are much better languages as Dylan (not Java). Better still functional languages of the ML family as OCaml from (INRIA) also with OO support that reach quasi C++ speed and superior memory perfomance, 5-10 times more productive than C++ or Java.
Right 9 of 10 users are *stupid* analphabets, even they believe that they aren't. That's the customer's niche of Microsoft the Click-Click World where you don't have to know, only exercise your 'intuition' or after some cut and try tests become 'instinct-conditioned'. You ask why?. The answers is because 'all do the same way' (a well known and studied sychological-mass effect). That folks are pretty easy targets for Microsoft, (really they don't have ANY choice) so the real target is the rest of *non stupid* folks. That's why M$ is taking seriously track of Linux. GPL is bad to M$ as it offers more freedom to choose (another interesting sychological effect) and these guys are not prone to go back to M$ vision, as they found they can 'learn' tech and interact and colaborate with an open community. They don't need to pay for OS, tools or languages, patchs comes sooner, apps run more stable, and discover that M$ 'more productive way' is a myth. So M$ let live these guys, stop the lies, stop the FUD.
Right perhaps at first sight, but with a little knowledge is VERY different. ie: I am sure that C++ is quite more unreadable (lots of code completely useless, meaningless not related with the real app to solve = lot of NOISE = lots mistakes) than OCaml. Perhaps isn't your case but many of the 'readness critics myth' are done by programmers biased by the stuffs they know, trying to read that way something too different. But syntax isn't the real issue, what a programmer really need is POWER which is related to semantics. My personal experience with two 'clipper' programmers with no special math backgound and no OO knowledge is that they wrote some 'correct' code in OCaml and they couldn't do it in C++. Code maintenance indeed is much more easy in OCaml! than C++ or Java, and it is proved to me that OCaml needs less coding and debug effort and less maintenance because code is safer. If Ocaml will be 'adopted' or not, it is premature to answer (perhaps will never reach the huge popularity of some craps) but it is growing and I am sure that it will stay growing because it is a BIG language.
If I have to chose to drive a 'Nissan V16' or a 'Ferrari Testarossa' no doubt I chose the 'Ferrari'.
The good language exists yet. It's name is OCaml and it's supported by INRIA France. It is far better than Java C++ and any scripting like Perl Python PHP... It is 4 - 10 times more productive than Java, 2 - 4 times faster with a perfomance near C++, less memory usage, strict typing system don't let you make stupid mistakes, automatic type inference (you dont need to waste your time writing and checking among modules useless declarations messed by casting). It is functional, with imperative and OO support, extensible semantics and easy C or C++ interface,
GC, high level native types like tuples lists. It runs with a very fast bytecode interpreter and a superb native compiler, GUI, database... libs. I have being programming more than 10 years C++ and 5 years Java and OCaml is far ahead. About Basic no comments (I don't want to offend anybody).
XP is a NAIVE (some silly) idea. it reminds me the 10 steps to lose weight or 10 ideas on how to get rich.... If I work with a guy at my shoulder, it don't guarantee that the resulting code will be better. If some guys are doing intensive test it does not mean that they are finding bugs. If I rebuild a project by every 24 hours I am diverting effort on a secondary activity. First you must care for the design and it is better to do it with few experimented persons. The result desing will impose the correct tools to build the solution, so it implies that only some programmers of the staff would be able to be assigned. Before coding you must prove that the model and algorithms for the solution are correct, and there are no harmfull side-effects. Again it is an activity for few selected persons. The most silly concept is designing while building (who is a very common practice, also as cut-and-paste), the result is POOR, BUGGY CODE and finally WASTED TIME. XP concepts are more like a recipe to be applied in an activity wich indeed needs much more than a simple recipe.
Excuse me for my poor english.
Sorry but I strongly disagree your model. Moreover
I believe all this middleware layer is a misconcept. Why?
1) more to learn, more code hard debug, less perfomance, less stability, bulky adm apps to know
whats happend, not obvious advantage ORB's to
plug because they need stubs (IDL another bad language) and lacks your propietary needs, poorer
system uptime, high maintenance costs (derived from the lack of having 'broken apps') to maintain
your client software and client data sync, updated etc..etc.
2) Have you ever seen a serious study (not vendor
propaganda) that demonstrate middleware is cheaper
than old dinosaur mainframe deployment? I have
being searching for more than one year and the
only numbers I've found (from banking industry)
states that Client/Server tech costs 1.5 times more. I have spent about 6 month developing CORBA
apps (DELPHI + VISIBROKER + NT) and results were
not as much we expected. In fact we had stability
problems, poor exception handling etc.. finally
we solved much better with an old-fashioned socket
app.
3) The reality if you see the polls is less than
10% of programmers are using these tools.
4) Development cycle is diverted from its main
goal that is the implementation of the real straigth efficient solution in detriment of some
'theoric abstract model'. There are several hundreds of functions in bad designed foundations
classes and libraries to add more!. So you must
select what is really usefull and you will keep
very few, but the time you spent diving is lost.
The Alternative NEW MODEL. 2 level terminal/server
1) Broken apps must be gathered in the server side
(nothing new thats the way done before Client/Server).
2) Standarization of messaging (XML?) and protocol
data managment to deal with ultra-thin-clients
(terminal devices). Same scheme would be used for
Host to Host interaction.
3) Server Front-end to perform message mapping and
service scheduling, load balancing, care of connections, queueing, session and protocols. Services are absolutely isolated from the outside world. This Server Front end (yet I have implemented one) is surprisely simple to do almost
anything you need and introduce a very low overhead in overall process. My benchmarks showed
me it can deliver 2000 transactios per second in a
modest Linux Box PIII 64MB RAM.
4) Clients apps obviously runs at the server side the client device becomes an ultra-thin-client (a
sort of a more generalized internet browser) that
runs the specific 'applet' (maybe JAVA or other better language with less resource consumption [interpreted Ocaml]) so software updates are automatic and no distrubuted data to synchronize.
Multiple hardware techs could be easily supported
ranging from instruments, telecom-devices, POS
Palms, cellular phones, PC based terminals etc.
5) This arquitecture is quite much simpler and
cheaper to implement stable wide range solutions.
With Standarized Ultra-Thin-Clients you can
concentrate all development effort in the rigth
place THE SERVER. No propietary software in the
Client (terminal) side.
I hope that in a few years Client/Server model and
all associated middleware finish. The real battle
is in the server side. Clientes are TERMINALS.
Arturo Borquez
Sorry about my english (I am spanish parlant)
I agree 100% you that the real battle is on the server side and Microsoft need time (.NET) to do something? (I believe they don't know what) because windows 2000 is flawed. Distributed process and language interoperability are to be trashed in a few years, so I view in the future terminals (or ultra-thin-client at the client side) driven by servers (as has being done in the 'dinosaur era'), an enhanced TCP/IP, a message system-protocol as simple and efficient as possible (none of actual mess) to hold terminal to host and host to host interaction.
Slashdot Mirror
Perhaps Haskell is more elegant, but you must agree that OCaml is a very good blend of expresiveness, speed, powerfull libraries and efficient implementation. It is the apropriate language for those C/C++ Java Perl and Python programmers that are searching for a more powerfull language.
Yes you are right. It is silly assume that in the real worl all programmers are gurus. But it has sence that there are better languages and poorer languages and that means expresiveness, CPU & memory perfomance, training curve, support libs. reliability, productivity, maintenace ... finally
$$$ that make a significant difference.
Switching to OCaml perhaps is not as expensive as you think. It is by far more harder recycle a C/C++ programmer as they are get used to deal at very low level. My experience with VFP programmers is about to 3 month (45 min/day) to get a productive OCaml programmer. In the long term it is possible to achieve BIG savings. I do not recommend to port graphics apps but non-grapichs as services indeed yes.
Delphi & Kylix are nice graphical IDE's with a vast library support builded arrond a poor language PASCAL or OO PASCAL both with a flawed type system.
OCaml : http://caml.inria.fr GCaml : http://pauillac.inria.fr/~furuse/generics/
If you learn OCaml properly you'll become addicted and will find all C/C++ stuff a great annoyance!
Tim you are right, a good programmer is much more productive than a bad programmer, but a good C/C++ programmer vs a good OCaml (ML, Clean, Haskell...) programmer the former will NEVER achieve the productivity of the later. I have a record with more than 3 years of C/C++ programming and 1 year in OCaml that shows me this fact. By the way C/C++ are really bad toys compared with OCaml or ML's.
Type Inference checks for you at compile time that your programm (variables) are coherent so none or minimal annotations are needed (which is a nice feature to avoid massive debuging). The type system has a solid foundational theory as opposed with C/C++ Pascal ... which have flawed type systems
(or how a type system can do an awfull job).
All this 'real languages' are history. Functional languages with solid and coherent theory behind are to be the 'real languages' for the future.
YES YES YES, OCaml is the nicer language I ever found. It is quite expresive and readable in terms of the solution (not dealing with stupid annotations and castings to get cheated elsewhere) It has being proved to me as I have some measures that OCaml is about 3-5 times more productive than C++ and debbuging is almost unneeded. You forgot to say that OCaml has TYPE INFERENCE, a true professional type system and a great MODULE system. My experience with OCaml is the best and as a programming language I've put it over Python, Java, Pascal or C/C++. Functional paradigm is far better to imperative style. Choosing the correct programming language MATTERS.
C++ has never being a great language: 1) It's type system is a failure (same as pascal), incoherent and misconcepted design. Real and usefull type systems can be found in ML languages that can found almost errors at compiling stage. C++ and a lot of others are really UNSAFE programming languages. 2) No Garbage Colector. (more memory mistakes) 3) Bloated and useless declarations and syntax. Most C++ programmers only use a subset of the language. 4) Too low level (as Java and pascal) to be reliable in large proyects. 5) Low productivity, a large debugging and testing effort. 6) Low level of expresiveness and abstraction. The programmer waste a lot of time dealing with irrelevant stuffs. My conclusion: It is very difficult to C++ to evolve to a BIG language as the basement is poor. Also in the OO arena are much better languages as Dylan (not Java). Better still functional languages of the ML family as OCaml from (INRIA) also with OO support that reach quasi C++ speed and superior memory perfomance, 5-10 times more productive than C++ or Java.
Right 9 of 10 users are *stupid* analphabets, even they believe that they aren't. That's the customer's niche of Microsoft the Click-Click World where you don't have to know, only exercise your 'intuition' or after some cut and try tests become 'instinct-conditioned'. You ask why?. The answers is because 'all do the same way' (a well known and studied sychological-mass effect). That folks are pretty easy targets for Microsoft, (really they don't have ANY choice) so the real target is the rest of *non stupid* folks. That's why M$ is taking seriously track of Linux. GPL is bad to M$ as it offers more freedom to choose (another interesting sychological effect) and these guys are not prone to go back to M$ vision, as they found they can 'learn' tech and interact and colaborate with an open community. They don't need to pay for OS, tools or languages, patchs comes sooner, apps run more stable, and discover that M$ 'more productive way' is a myth. So M$ let live these guys, stop the lies, stop the FUD.
Right perhaps at first sight, but with a little knowledge is VERY different. ie: I am sure that C++ is quite more unreadable (lots of code completely useless, meaningless not related with the real app to solve = lot of NOISE = lots mistakes) than OCaml. Perhaps isn't your case but many of the 'readness critics myth' are done by programmers biased by the stuffs they know, trying to read that way something too different. But syntax isn't the real issue, what a programmer really need is POWER which is related to semantics. My personal experience with two 'clipper' programmers with no special math backgound and no OO knowledge is that they wrote some 'correct' code in OCaml and they couldn't do it in C++. Code maintenance indeed is much more easy in OCaml! than C++ or Java, and it is proved to me that OCaml needs less coding and debug effort and less maintenance because code is safer. If Ocaml will be 'adopted' or not, it is premature to answer (perhaps will never reach the huge popularity of some craps) but it is growing and I am sure that it will stay growing because it is a BIG language. If I have to chose to drive a 'Nissan V16' or a 'Ferrari Testarossa' no doubt I chose the 'Ferrari'.
The good language exists yet. It's name is OCaml and it's supported by INRIA France. It is far better than Java C++ and any scripting like Perl Python PHP ... It is 4 - 10 times more productive than Java, 2 - 4 times faster with a perfomance near C++, less memory usage, strict typing system don't let you make stupid mistakes, automatic type inference (you dont need to waste your time writing and checking among modules useless declarations messed by casting). It is functional, with imperative and OO support, extensible semantics and easy C or C++ interface,
GC, high level native types like tuples lists. It runs with a very fast bytecode interpreter and a superb native compiler, GUI, database ... libs. I have being programming more than 10 years C++ and 5 years Java and OCaml is far ahead. About Basic no comments (I don't want to offend anybody).
XP is a NAIVE (some silly) idea. it reminds me the 10 steps to lose weight or 10 ideas on how to get rich .... If I work with a guy at my shoulder, it don't guarantee that the resulting code will be better. If some guys are doing intensive test it does not mean that they are finding bugs. If I rebuild a project by every 24 hours I am diverting effort on a secondary activity. First you must care for the design and it is better to do it with few experimented persons. The result desing will impose the correct tools to build the solution, so it implies that only some programmers of the staff would be able to be assigned. Before coding you must prove that the model and algorithms for the solution are correct, and there are no harmfull side-effects. Again it is an activity for few selected persons. The most silly concept is designing while building (who is a very common practice, also as cut-and-paste), the result is POOR, BUGGY CODE and finally WASTED TIME. XP concepts are more like a recipe to be applied in an activity wich indeed needs much more than a simple recipe.
Excuse me for my poor english. Sorry but I strongly disagree your model. Moreover I believe all this middleware layer is a misconcept. Why? 1) more to learn, more code hard debug, less perfomance, less stability, bulky adm apps to know whats happend, not obvious advantage ORB's to plug because they need stubs (IDL another bad language) and lacks your propietary needs, poorer system uptime, high maintenance costs (derived from the lack of having 'broken apps') to maintain your client software and client data sync, updated etc..etc. 2) Have you ever seen a serious study (not vendor propaganda) that demonstrate middleware is cheaper than old dinosaur mainframe deployment? I have being searching for more than one year and the only numbers I've found (from banking industry) states that Client/Server tech costs 1.5 times more. I have spent about 6 month developing CORBA apps (DELPHI + VISIBROKER + NT) and results were not as much we expected. In fact we had stability problems, poor exception handling etc.. finally we solved much better with an old-fashioned socket app. 3) The reality if you see the polls is less than 10% of programmers are using these tools. 4) Development cycle is diverted from its main goal that is the implementation of the real straigth efficient solution in detriment of some 'theoric abstract model'. There are several hundreds of functions in bad designed foundations classes and libraries to add more!. So you must select what is really usefull and you will keep very few, but the time you spent diving is lost. The Alternative NEW MODEL. 2 level terminal/server 1) Broken apps must be gathered in the server side (nothing new thats the way done before Client/Server). 2) Standarization of messaging (XML?) and protocol data managment to deal with ultra-thin-clients (terminal devices). Same scheme would be used for Host to Host interaction. 3) Server Front-end to perform message mapping and service scheduling, load balancing, care of connections, queueing, session and protocols. Services are absolutely isolated from the outside world. This Server Front end (yet I have implemented one) is surprisely simple to do almost anything you need and introduce a very low overhead in overall process. My benchmarks showed me it can deliver 2000 transactios per second in a modest Linux Box PIII 64MB RAM. 4) Clients apps obviously runs at the server side the client device becomes an ultra-thin-client (a sort of a more generalized internet browser) that runs the specific 'applet' (maybe JAVA or other better language with less resource consumption [interpreted Ocaml]) so software updates are automatic and no distrubuted data to synchronize. Multiple hardware techs could be easily supported ranging from instruments, telecom-devices, POS Palms, cellular phones, PC based terminals etc. 5) This arquitecture is quite much simpler and cheaper to implement stable wide range solutions. With Standarized Ultra-Thin-Clients you can concentrate all development effort in the rigth place THE SERVER. No propietary software in the Client (terminal) side. I hope that in a few years Client/Server model and all associated middleware finish. The real battle is in the server side. Clientes are TERMINALS. Arturo Borquez
Sorry about my english (I am spanish parlant) I agree 100% you that the real battle is on the server side and Microsoft need time (.NET) to do something? (I believe they don't know what) because windows 2000 is flawed. Distributed process and language interoperability are to be trashed in a few years, so I view in the future terminals (or ultra-thin-client at the client side) driven by servers (as has being done in the 'dinosaur era'), an enhanced TCP/IP, a message system-protocol as simple and efficient as possible (none of actual mess) to hold terminal to host and host to host interaction.