Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Power of Modern Programming Languages is That They Are Expressive, Readable, Concise, Precise, and Executable (scientificamerican.com) 268

An anonymous reader shares a Scientific American article: Programming has changed. In first generation languages like FORTRAN and C, the burden was on programmers to translate high-level concepts into code. With modern programming languages -- I'll use Python as an example -- we use functions, objects, modules, and libraries to extend the language, and that doesn't just make programs better, it changes what programming is. Programming used to be about translation: expressing ideas in natural language, working with them in math notation, then writing flowcharts and pseudocode, and finally writing a program. Translation was necessary because each language offers different capabilities. Natural language is expressive and readable, pseudocode is more precise, math notation is concise, and code is executable. But the price of translation is that we are limited to the subset of ideas we can express effectively in each language. Some ideas that are easy to express computationally are awkward to write in math notation, and the symbolic manipulations we do in math are impossible in most programming languages. The power of modern programming languages is that they are expressive, readable, concise, precise, and executable. That means we can eliminate middleman languages and use one language to explore, learn, teach, and think.
This discussion has been archived. No new comments can be posted.

Power of Modern Programming Languages is That They Are Expressive, Readable, Concise, Precise, and Executable

Comments Filter:
  • I swear the computers are training us more than we're training them though. Natural language is changing, even my kids change the way the talk when they are talking to the amazon dot.
    • I'm waiting for Douglas Adam's Desk based computer interface. You sit at it and start working to solve your problem, the AI looks at what you are doing, infers the problem you are trying to solve, then solves it for you. Seems like the best possible use of an AI. Of course, one might say Clippy tried to do that. But AI has come a long way.

    • Well, it's always been the easier option since the very invention of punch cards.
    • I swear the computers are training us more than we're training them though. Natural language is changing, even my kids change the way the talk when they are talking to the amazon dot.

      That's because they've figured out that the voice recognition is very limited in its capability.

      If everyone starts speaking "flat" English to these things, the manufacturers will have little motivation to ever improve the voice recognition.

      So, you are right.

  • What? (Score:5, Insightful)

    by Anonymous Coward on Monday May 01, 2017 @10:24AM (#54333551)

    With modern programming languages -- I'll use Python as an example -- we use functions, objects, modules, and libraries

    Who writes this shit? Confirming that C uses neither functions nor objects nor modules nor libraries

    • Re:What? (Score:5, Insightful)

      by AchilleTalon ( 540925 ) on Monday May 01, 2017 @10:49AM (#54333771) Homepage
      My first, second and third reaction too. And what you say for C is also true for Fortran. That guy doesn't know what he is talking about. Neither Fortran, nor C are first generation languages as he states it anyway. This article is total crap. Shame on you Scientific American for publishing that shit.
      • Re:What? (Score:5, Informative)

        by Anubis IV ( 1279820 ) on Monday May 01, 2017 @12:33PM (#54334753)

        Neither Fortran, nor C are first generation languages

        In fact, every language he mentions in the article is a textbook example of a third-gen language (3GL). I didn't see any mention of even a single first generation language.

        I'll give him the benefit of the doubt and assume he was trying to keep his writing approachable, but "first generation languages" has had an established meaning in this field for the last several decades, so misusing the terminology just makes it look like he has no idea what he's talking about. A far better way to phrase it would have been "In early high-level languages like FORTRAN and C [...]", since that would have been accurate while also being descriptive enough for most lay people to understand well enough.

        For anyone who doesn't know about them, programming language generations refer to the level of abstraction, NOT to when they were introduced:

        1. 1GL [wikipedia.org] = Machine code. Flipping bits to issue machine-specific instructions
        2. 2GL [wikipedia.org] = Assembly. Using human-readable text to issue basically the same instructions
        3. 3GL [wikipedia.org] = Most high-level programming languages. Abstracting away machine instructions (e.g. using loops and function calls to abstract away jump instructions) to the point that it's both easier to use and mostly machine-independent (e.g. Fortran, COBOL, C, C++, C#, Java, Python, Ruby, Go, Rust, Swift, etc.)
        4. 4GL [wikipedia.org] = Languages that, among other things, abstract generating reports, generating UIs, and/or handling collections of information (e.g. SQL, some 3GLs with libraries, etc.)
        5. 5GL [wikipedia.org] = Languages where you describe the problem and let the computer come up with the algorithm (e.g. Prolog)

        All of which is to say, starting off an article with a glaring misuse of established terminology is a great way to get anyone with a passing awareness of the topic to immediately dismiss anything he has to say. As a professor, I'd hope he'd have a better awareness about the importance of using those terms correctly. And as the publisher, I'd hope that Scientific American would have an editor who would recognize when they were out of their depth and would need to call in a domain expert to proof the text.

        • by mikael ( 484 )

          I worked with Prolog. You specify the problem as a series of associations and constraints. Then the system would run a brute force scan through all the possible combinations and come up with the possible solutions. Worked great for generating university timetables and solving any combinatoric problem.

          Maybe Matlab could be 5GL, since many companies seem to use that to generate algorithms.

    • Well, C only supports the first thing. Modula-2 adds modules, but not objects, for example.
      • C does not just support functions - it supports libraries too. Arguably it also supports objects as well since you can put function pointers in a struct but by that point most people would just use C++. The only thing C does not support is a module.
        • *How* does C support libraries? About the only thing it has is static linkage for things you don't want to see outside a compilation unit. Everything else is open to individual implementations to make a mess of it. At best there is an assortment of implementation choices made by most implementors.
        • by HiThere ( 15173 )

          C doesn't support libraries, that's done by the linker. But C does support modules. It's not even convoluted. You just make each module a separate file, and only disclose those you want visible in the header file. Static and external also help when used in various places.
          Note: The actual connection of the thus created modules is still done by the linker. But because of the definition of the header file and the static and external keywords it's fair to say that C supports them.

          That said, I don't like t

        • OOP is only a style, not a thing. A language can have special features to support it, but code doesn't lack objects just because the language doesn't have special features for that.

          If it is programmed using OOP semantics then it is OO regardless of language. Lots of OO is done in C. Even the whole Gtk library is OOP in plain C. In the 90s I had all the headers printed out as a desk reference.

          So you don't need a struct. You could use one, but generally with OOP in C all you have to do is pass the reference t

    • The people who write stuff like this also write mission statements like:

      DoIT’s mission is to empower the State of Illinois through high-value, customer-
      centric technology by delivering best-in-class innovation to client agencies fostering collabora
      tion and empowering employees to provide better services to residents, businesses, and visitors.

      Giveth me a break.

    • With modern programming languages -- I'll use Python as an example -- we use functions, objects, modules, and libraries

      Who writes this shit?

      Obviously, not a programmer.

      • With modern programming languages -- I'll use Python as an example -- we use functions, objects, modules, and libraries

        Who writes this shit?

        Obviously, not a programmer.

        Those who can, do.
        Those who can't ...

    • Also bizarre to call Python a modern language. It's been around a long time and is fundamentally not that different from other scripting languages that showed up around that time.

      If you want expressive, readable, concise, precise, and executable, then use Scheme! Sure, you have to actually *learn* the language first, but that must be true for every language.

  • I remember reading about why COBOL so much superior to FORTRAN. And sounds exactly like the summary!
    • by TWX ( 665546 )

      My dad was a COBOL programmer for more than 30 years, learned on an IBM System 36 in the late sixties and early seventies. He maintained that COBOL was very human-readable, especially compared to languages like C where something like

      for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

      will clean-compile.

      If one considers the growth of business-computing, business has always been about what the nontechnical person can understand, as the nontechnical person is usually the business manager. That's in-part why nowadays everything is either GUI-only or at least h

      • by hughbar ( 579555 )
        Yes, I started with Fortran at school and then COBOL for my first few jobs. Fortran (or FORTRAN, if you insist) was generally used for science and maths (we had a big program to calculate UK tides, several expensive mainframe hours, for example) and COBOL for accounting, bill of materials etc.

        COBOL was/is a lot more readable because of the pseudo-english syntax. We used to try and write 'dirty' COBOL too: PERFORM UNNATURAL-ACTS VARYING PARTNERS FROM ...

        Those long winter evenings just flew by.
      • Seriously? COBOL is a programming language developed for business NOT because there wasn't a graphic user interface but because it was developed to have functions used in business, finance, and administrative systems. No other programming language can easily do what COBOL does. That's why it has persisted for 57 years. Moron.
    • As part of my retirement plan, I will seriously brush up on COBOL in the year 9995. In about the year 9997 everyone will start getting worried about the Y10K problem. People will think Y10K will be the end of civilization as we switch over to five digit years. There will be lots of COBOL work available.
  • by geekmux ( 1040042 ) on Monday May 01, 2017 @10:30AM (#54333607)

    "...That means we can eliminate middleman languages and use one language to explore, learn, teach, and think."

    One solution for all? Never gonna happen.

    Some prime examples:

    "That means we can eliminate the standard system and use one metric system to measure everything."

    "That means we can eliminate the right-side driving wheel and everyone will drive on the same side of the road."

    "That means we can eliminate all of the world's individual spoken languages and use only one language to communicate."

    Humans are stubborn. Like really fucking stubborn.

    • If there were one perfect programming language, everyone would be using it already. That's why programming language fanboy wars are fun to watch.

      A hammer is better.
      No! A wrench is better!
      You're both wrong, a screwdriver is the best!
  • concise? readable? (Score:5, Insightful)

    by petes_PoV ( 912422 ) on Monday May 01, 2017 @10:35AM (#54333649)

    I don't buy this. A simple hello world in Java is much more complex and wordy than the same functionality in 50 year-old BASIC. And any language that relies on whitespace to modify the program flow cannot be described as readable.

    And many object-oriented programs have so much of their basic functions hidden away in inheritance and class definitions that a printed form of a program is impractical. I would not call that "progress".

    As for natural language, it tends to be incredibly imprecise: the meaning is only apparent when the context of its use is taken into account. I would love to see a translator that tried to convert "natural language" sarcasm into executable code. But I wouldn't want it running in my driverless vehicle or airplane.

    • Readable perhaps. Unambiguous, not so much. Concise? YMMV.
    • by Megol ( 3135005 )

      I don't buy this. A simple hello world in Java is much more complex and wordy than the same functionality in 50 year-old BASIC. And any language that relies on whitespace to modify the program flow cannot be described as readable.

      Now use the 50 year old BASIC to do a modern task in a way that is portable and provides a graphical output to an arbitrary device.

      I don't think esoteric languages was mentioned in the article (not that I've read it - but it would make no sense), what real language are you thinking about that uses whitespace for control flow?

      • by Dog-Cow ( 21281 )

        ... what real language are you thinking about that uses whitespace for control flow?

        Is that a serious question?

    • ...and "executable"? Aren't *ALL* programming languages executable? Isn't that the point?
  • by passionplay ( 607862 ) on Monday May 01, 2017 @10:41AM (#54333699)
    Unless you're talking about C, or D, the fact of the matter is that you've hidden all the computational overhead in multiple layers of automated translation behind your syntactical sugar.

    Case in point: non-memory managed languages don't need to manage memory - memory requirements for these programs are huge due to inadequate planning. How many programmers take into account object pooling?

    Case in point: The Motorola Startac was a very limited device but had its programming in hardware - you could not type faster than the device. New smartphones have 2-3Gb in memory and yet are less responsive.

    Case in point: a field programmable gate array was never intended for production use - yet every computer today uses these

    Case in point: how many Java programmers think about += string concatenation versus =+ string concatenation?

    While the K&R manual is correct that every complex problem can be further simplified by one more level of indirection, it is not true that there is no cost.

    Our computers today are 1000 times more powerful and solve the same problems as before. So what has changed? Our efficiency in coding as dropped and we are not using the resources at hand to make better solutions but sloppier ones that require less effort on our part but more computational overhead.

    We have become lazy and complacent and we call it progress. Until our programs can optimize to the level that we can generate by hand, I would not deem to consider our current state of programming languages an improvement in anything other than readability.
    • P.S. Every example provided in Python can be done as readable in C or D or even C++. It is not a function of the language but a function of the programmer.
      • by zifn4b ( 1040588 )

        P.S. Every example provided in Python can be done as readable in C or D or even C++. It is not a function of the language but a function of the programmer.

        Yup, in C++ it's even easier now because C++11 has language support for lambda's

    • Our computers today are 1000 times more powerful and solve the same problems as before. So what has changed? Our efficiency in coding as dropped and we are not using the resources at hand to make better solutions but sloppier ones that require less effort on our part but more computational overhead. We have become lazy and complacent and we call it progress. Until our programs can optimize to the level that we can generate by hand, I would not deem to consider our current state of programming languages an improvement in anything other than readability.

      While I agree with your criticisms of TFA, I think it not quite correct to assume that "require less effort on our part" or "readability" are unimportant pieces of the picture. As I see it, software has multiple kinds of unavoidable costs: cost to design, cost to implement/code, cost to test, cost to maintain, cost in hardware resources to run.

      Using a high-level language may increase the last cost, while reducing all the other kinds of cost. That may well be the wise tradeoff.

      Of course, that sounds good u

    • Case in point: non-memory managed languages don't need to manage memory - memory requirements for these programs are huge due to inadequate planning. How many programmers take into account object pooling?

      Sounds like several issues being conflated into one, badly. Case in point: Java and Smalltalk not having space-efficient headerless value types being a distinct problem from having automated memory management, or object pooling fucking up generational memory management schemes.

    • by zifn4b ( 1040588 )

      Unless you're talking about C, or D, the fact of the matter is that you've hidden all the computational overhead in multiple layers of automated translation behind your syntactical sugar.

      Surely you must mean C++ not C. What would you call Boost? Syntactical sugar?

      Furthermore, not all applications need 100% optimized performance or scalability to meet the demands of millions of users. Real seasoned programmers use the right tool for the job based on what's needed not some ivory tower bullshit. If we need 3 or 4 9's of high availability we use one approach, if we expect a small number of concurrent users on some mobile app, we use a different approach.

      No offense, but you sound inexperienc

    • by mccalli ( 323026 )
      As you have done with C - the CPU speaks binary, not C. Multiple layers of automated translation have been applied to your syntactic sugar. Otherwise known as - compiling.
    • by Megol ( 3135005 )

      Unless you're talking about C, or D, the fact of the matter is that you've hidden all the computational overhead in multiple layers of automated translation behind your syntactical sugar.

      What about all other languages for system programming* or otherwise? You are wrong BTW, even _real_ high level languages can have thin abstraction layers.

      Also I don't think you understand what the term syntactic sugar means - it isn't an indication of abstraction but an indication of a feature intended to be "sweeter" for the programmer. Garbage collection isn't syntactic sugar, the C pre/post increment support is. Many languages support alternative looping constructs that reduce typing compared to a generi

  • by Archtech ( 159117 ) on Monday May 01, 2017 @10:43AM (#54333711)

    If the assertion is that one language can be used for everyday purposes and also for specifying programs, it is hopelessly wrong. The merit of a programming language, like any other scientific specification, is that it is exact, precise, correct, and unambiguous. If it is easy to understand, that is a nice bonus - but it cannot be a high priority.

    Natural language, on the other hand, revels in deliberate ambiguity, multiple shades of meaning, and even saying slightly different things to different listeners. That's why synthetic languages like Esperanto never succeed beyond a small circles of fans: you can't write poetry in them, or even any stirring emotional prose.

    The purpose of programming languages is to eliminate doubt and ambiguity - to perfect communication. The purpose of natural languages, inasmuch as they have a single purpose, is to sell, seduce, persuade and - yes - confuse.

    • That's why synthetic languages like Esperanto never succeed beyond a small circles of fans: you can't write poetry in them, or even any stirring emotional prose.

      Is that really true? I don't know, I'm wondering.

  • Who wrote this rubbish? I remember a time long ago when Scientific American was worth reading. This reads more like something from Popular Science.
  • by the_skywise ( 189793 ) on Monday May 01, 2017 @10:45AM (#54333733)

    Programming languages are "executable" now?

    Really...

    He's talking about interpreted vs compiled and interpreted languages have been around before C (BASIC anyone?!)

    And as others have posted COBOL made these same claims years ago.

    Expressive isn't necessarily better and really depends on your interpretation of such. It is far easier to "express" new hardware concepts/manipulations (like memory handling) in C than it is in Java. It is also easier to make "Expressive" code in C++ much to the detriment of most maintainers!

    Python and Java (like BASIC before them - and we're talking about the one with line numbers, not that MS bs) provide low barriers to programming - code, run, repeat. They're great for learning and beginners and to quickly hammer out program concepts. With faster hardware these days you generally can get away with the performance you get from these languages without having to transcribe them to a lower level language (C, Assembly).

    It used to be standard practice to write the algorithm in C then run the C parser to output the code directly to the assembly it was going to generate and then hand-tweak the assembly! That we don't need to do THAT anymore is a testament to the hardware and less to the languages used. (and in some cases because you can't anymore because the hardware is too disparate - IE phones)

  • Non-modern programming languages are not executable? What does that mean? They can obviously be compiled/interpreted into executable code, just like modern languages.

    • It means that code can be evaluted automatically. As opposed to, say, informal program specifications. I know, it sounds trivial but there's a lot of push to have as many things executable as possible. Specifications, ideally, because human translators make mistakes. Anything that can be written down as code can be manipulated automatically, which is a huge win in a field that is all about automation.
      • I'm not sure I follow.

        Wouldn't the proper term then be "evaluatable"?

        I understand in devops how even server configurations are "executable" but those aren't programming languages being used to generate those configurations but JSON or some other definition format that may contain executable chunks (like javascript, shell calls, etc).

        And even though HTML and XML have the term "language" in them they're not "programming" languages per se.

  • By using a modern programming language you no longer need to think or plan. You can just tell something to go do. I'm sure that is in no way related to the garbage some of those languages have produced.

    • With a modern language, you DO need to think AND plan, if you are building any non-trivial program and it needs to be maintainable.

      For trivial programs there are many posers who can quickly turn out unmaintainable crap code heavily copy/pasted from Google and Stackoverflow without thinking or planning.

      The posers can't build the large non-trivial program, even in a modern language. Thinking and planning is still necessary. Experience also counts. (Experience measured in code and learning from past p
  • by frovingslosh ( 582462 ) on Monday May 01, 2017 @10:59AM (#54333839)

    By executable the author actually means interpreted ..Any decent programmer knows this means the language is slower than need be. Translation is not a bad thing, it is another word for compiling and/or assembling, the process that converts human readable code into actual machine instructions. Any language could be compiled, but in practice some languages (for example C) are compiled (and assembled) while others (for example Basic) are typically interpreted. Interpreting makes the language slower, as a step that occurs one time in the creation of a compiled program before the program is ever run must now happen each time the program is run (and in many cases it happens each time a line of code is rerun, although there are "just-in-time" tricks that can avoid the repeated interpreting.). Interpreted languages are an unfortunate side effect of faster computers, people get lazy, want to not have to go through a separate compilation stem when making a simple change, and figure the interpreted language is "good enough" for the user, even though it means the program will run slower than need be each time every single user runs it.

    Interpreted languages have their place. Basic was a good introductory teaching language in its day, as it was intended to quickly let beginners write and test their code. But only the feeble minded would have tried to use it for production coding. There are great special purpose interpreted languages like AWK that are quite good for quick and dirty one time tasks. And I'm even saying all of this as being a Forth programmer who even was on a team that implemented a Forth on the C64. (Forth actually does a lot of the "compilation" when each line or word is written, but it is still inefficient as it spends most of its time in subroutine calls and returns). But interpreted languages will always sacrifice speed, and you can write a compiler to translate any interpreted language into true machine code (although in many cases it isn't worth doing).

    • by K. S. Kyosuke ( 729550 ) on Monday May 01, 2017 @12:29PM (#54334715)
      I've read the article and I didn't notice any connection between "executable" and "interpreted" that you seem to be making. By "executable", the author very clearly means "executable". Executable means a computer can execute it, period. The mechanism is immaterial here. And had you actually read the article, it would have been obvious to you because of the contrasting comparison with pseudo-code example that *cannot* be executed - it's not something you can type into a computer in an unchanged form and still have it run.
  • ... but also a bit naive. From a bit more pessimistic perspective, programming with modern languages and libraries is a bit like building a bridge from hundreds of uncertified components that are not really designed for the task and have mostly been developed by hobby-engineers. There are safety nets everywhere, so you cannot harm yourself easily, but in the end you'll never know whether the bridge will hold or not...
  • Just from the quote.... Is that trying to suggest that C doesn't have functions?

    You can write good, modular code in almost any language. And I've *seen* spaghetti python, as well as enough other languages.

    And making the code clean and readable depends on the programmer, and whether they pay any attention to standards and best practices.

  • This description is not modern at all.

    I'll use Python as an example -- we use functions, objects, modules, and libraries to extend the language, and that doesn't just make programs better, it changes what programming is.

    Ok young whipper-snapper programmer that thinks you're all that and a bag of potato chips and you're using some new fancy language that supposedly has all these "new" features. Check out, just to name a few, these languages that have been around for several decades: C++, Pascal, Smalltalk, Java... even C# has been around for 15 years now. Do I need to continue? Even Python isn't really all that new.

    This article just makes the author sound like they have no clue what

  • Absolute garbage.

    Baseless language holy war spoken from ignorance and a skewed vision of the past. "It uses libraries!" Really? Is that really all you're trying to bring to the table here? And he discovers that you can use actual code rather than pseudo code?

    Scrap away the buzzwords and the remaining statements are just plain false. Does he think C doesn't make use of libraries?

    It's garbage and shouldn't have made it's way to Slashdot. Come on msmash, are you just trying to get a rise out of us?

  • Poster forgot to include that modern languages are verbose.

    For example, Javascript is insanely verbose for even the simplest of things.

  • by OneHundredAndTen ( 1523865 ) on Monday May 01, 2017 @03:40PM (#54336581)
    Nothing much to see here - the author of the article is also the author of a book on Python and wants, understandably, drum up interest.

"Atomic batteries to power, turbines to speed." -- Robin, The Boy Wonder

Working...