This is s long-standing bone of contention in the SE community, going back at least to the era of FORTRAN vs. Algol (I think similar arguments were trotted out even for FORTRAN in preference to writing programs in Assembler).
Putting aside the question of external interfacing (UIs, machine/device access, communications) it's arguable that one should be able to express pretty much any meaningful computation in any reasonably well-designed general-purpose programming language. In practice this involves varying levels of complexity, effort required, and awkwardness of expression arising from the choices made in specifying the language. So, after that the issue pretty much boils down to interfacing libraries/capabilities and personal preference. Now, computer programs are designed to DO something, and often in particular areas of inquiry there's a need to do a variety of related somethings, usually requiring some more domain-specific functionality than is offered by a raw general-purpose language. Further, the well-known general-purpose languages have been procedural in nature, and it's arguable (and has been extensively argued) that some problems are more easily addressed using a different computational model (declarative, functional). So the next question is something like "elegance of expression": how easy is it to specify tasks of interest without a lot of overhead and irrelevancy? Add-on libraries can address some of this for a general-purpose procedural language; but there's also something to be said for having a task- or domain-focused language that conforms more directly to the problem space. The more complex, abstract, and abstruse the problem domain becomes; the more likely it is that a specialized language will do a better job of handling the problems in an easily manageable fashion. Conversely, languages that have tried to be all things to all developers, by including every conceivable feature (e.g. PL1, Ada, even C++) are pretty roundly criticized for being too cumbersome to learn and use. Is there a happy medium somewhere? The explosion of languages you ask about says maybe not. As long as we're using general purpose computers to engage a variety of complex tasks; I think we're likely to continue to see a variety of computer languages intended to simplify addressing those tasks. Stephen Posey [email protected] -----Original Message----- >From: xiaorang <[email protected]> >Sent: Jul 12, 2014 7:57 AM >To: 'Moderated List for the Discussion of Delphi Programming excluding > Database-related topics' <[email protected]> >Subject: Why do we need so many languages? > >The discussion trigger a thought in me, why do we so many languages? >I feel quite at home when using Delphi and I think C# is acceptable. >I have no good comment on java, I think it's slow and ugly. >As there are so many people using Java, so that java is so popular, I can >almost guarantee that the problem is in me. >Actually, most programming languages are equivalence, I don't see any >serious difference in the syntax of C# and pascal and java and vb and many >more. >(Although I believe there are some noticeable differences in languages like >lisp, prolog, javascript, etc.) >It is far from imposible for us to build a translator between any two >languages. >It seems they are made not for solving problems but simply for variety. >What do you think of it? >---------------------------------------------------------------------------- >There were two parts to the OP's e-mail. > >First, about his son learning to program. I believe that learning 3 >languages from 3 different families gives one the best grounding in >programming, since it helps the mind abstract programming >principles. I note that people who posted here have quite a few >languages under their belts. > >Second, the OP was concerned that a future release of Windows would >not support D6, and that he would have to port to another >environment, such as XE or Lazarus. As people have pointed out, >porting is usually a pain: even if the language stays the same, then >some (or many) of the components are not supported. But it is still >the case that porting takes way less time than writing from scratch, >since at least the business rules and program structure will not >change. And if you have no choice other than to change, you have to >buckle down and do it. > >Porting from one language to another can be even harder. Some tricky >bugs can happen because of differences in language assumptions (e.g. >port from Fortran to C and all your 1-based arrays are now 0-based >arrays, and you have to change and test a lot of code [except there's >a trick around that]). Or say port from C++ to Delphi; well, that >was a lot of fun! :-) > >But it's still a lot less work than rewriting from scratch. > >Even my personal toolkit: if I suddenly had to port from C, Delphi, >and Javascript to D, Lazarus, and Python, it would still take a lot >less time than developing from scratch. > >I would, however, likely have problems if I had to port my personal >toolkit to say Haskell. Because the nature of functional languages >is so different, that would probably require a full rewrite. A moot >point, since I don't have anyone beating down my door to write >Haskell code. :-) > >As far as learning a new environment, agreed that being a guru in a >new language/environment takes many months. However, IMHO being able >to be "decent" and "productive" does not take more than a few weeks >(or less depending on the language/environment). And if the >incentive is high enough (e.g. can't do it any other way, or the >client will pay megabucks for a Forth version), a few weeks in not >that much time. > >While it may be true that "the longer you stick to a certain >language, the more efficient you will be", the flip side of that is >that you could end up remaining an expert in something that is no >longer popular, so you'll be competing for fewer and fewer available >projects. > >In the end, it all comes down to a cost/benefit analysis. > > >At 02:57 AM 7/9/2014, Irwin Scollar wrote: >>Jerry Clancy wrote: >> >>>I agree with xiaorang My own programming days started 51 years ago >>>with 1401 Assembler and FORTRAN, then a year later with 360 >>>Assembler and PL/1 during the development of OS/360 in >>>Poughkeepsie, the first major commercial operating system. >> >>My programming experience is similar to Jerry's, starting a bit >>earlier in 1960 with an IBM 1410 and it's variable word-length >>Assembler and then Fortran II on a 36 bit IBM 7090, and later >>Fortran IV on a 32 bit 370/165. After a long happy interlude with >>my own DEC PDP 11/70 and RSX11M plus DEC Fortran, code was ported >>in the 1980's to Turbo Pascal on 286 PC's and DOS followed by Object >>Pascal and in the early 1990's to Windows 3, NT 3.5, NT 4, 2000, XP, >>Vista and Win 7 with Delphi through nearly all its incarnations >>right down to XE6 which I'm using today with Windows 7 x64. I test >>my executables with Win 8.1 for the few users who don't mind rubbing >>their fingers on small screens or haven't heard of Classic Shell, >>since that's the current laptop world. Tiny touch screens on >>mobiles are not for my satellite and aerial image work even for >>those whose eyesight is far better than mine is I think, so Fire >>Monkey is not installed.. >> >>In 54 years, I have learned that each port is an agonizing >>experience, especially if the hardware architecture and the >>operating system change significantly. In recent years, I have >>used crutches like writing a user interface in 32 bit Delphi and >>spawning 64 bit executables written in VS C++ when needed for memory >>intensive satellite imagery until Delphi XE2 became available. My >>current project, a clean switch to pure 64 bit code with XE6 for >>work with multi-GB sized images has meant abandoning most of the >>TurboPower suite because of the 32 bit incompatible in-line >>assembler (by Julian Bucknall? : Steve Posey? or ?) The JEDI >>JCL/JVCL libraries and the additional built-in string handling in >>XE6 help, but it's still a lot of work. >> >>Like Jerry writes: >> >>"... excepting trivial programs, the transition from one language >>environment to another is usually anything but quick, easy or >straightforward." >> >>I couldn't agree more. >> >>Irwin Scollar >>_______________________________________________ >>Delphi mailing list >>[email protected] >>http://lists.elists.org/cgi-bin/mailman/listinfo/delphi > >_______________________________________________ >Delphi mailing list >[email protected] >http://lists.elists.org/cgi-bin/mailman/listinfo/delphi > > > >_______________________________________________ >Delphi mailing list >[email protected] >http://lists.elists.org/cgi-bin/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
