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

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

The State of the Scripting Universe 131

Posted by timothy from the what-about-directing dept.
r.jimenezz writes "Via PragDave's blog I learned of an article by Lynn Greiner on the state of scripting languages, a.k.a. scripting dynamic languages. A number of influential personalities (Guido von Rossum, Damien Conway, PragDave himself and others) were interviewed and it's interesting to see how much their opinions coincide despite being interviewed separately. A lengthy but worthwhile reading."
This discussion has been archived. No new comments can be posted.

The State of the Scripting Universe More

The State of the Scripting Universe

Comments Filter:

  • Dun dun dun... (Score:5, Funny)

    by ciroknight ( 601098 ) on Wednesday March 23, 2005 @04:49PM (#12028145)
    The research firm reports that over 41 percent of the 666 developers surveyed use Perl, 32 percent use PHP, and 15.6 percent use Python

    The Number of the Devil of Programmers.. looks like it's as I always said, scripting languages are evil..

  • What defines a scripting language? (Score:4, Interesting)

    by tchuladdiass ( 174342 ) on Wednesday March 23, 2005 @04:56PM (#12028224) Homepage
    I have often wondered what makes a particular language a "scripting" language v.s. a "real" language. One thing scripting languages all have in common is that they are interpreted. However Basic is interpreted (even though some may dissagree that it is a "real" language), and there have been interpreted versions of Pascal and others.
    The best I can come up with is that a scripting language is an interpreted language that is normally attached to an application in order to allow the end user to automate functions within that app. So for example BASH programming is "scripting" since most of what you do is items that would normally be done at the command line. Same with Word/Excel macros. Also, TCL was designed to be attached to other programs (although the typical use is stand-alone). But I wouldn't put PERL in that catagory, anymore than GW-Basic or interpreted Pascal are scripting languages.
    So, what does a language need to be called a "real" language, other than being compiled?
    • Perhaps it's standardization? I'm just guessing here. Is there a IEFT/IEEE/ANSI/whatever standard for things like BASH, Ruby, and Perl?

      I'm not trying to be a wise-ass. I'm sincere here. Maybe a ratified standard by some authority is what sets COBOL, BASIC, and Ada apart from their more agile scripting counterparts, whether or not a compiler or interpreter implimentation exists.

    • I always considered it a top-down kinda thing.
    • The differences are rapidly shrinking. For example, there is very little technical difference between the way Java is compiled and ran and the Python is compiled and ran. It's really more a matter of feel and attitude than anything else.
    • I would consider any programming language directly run from a text file a scripting language.
      • Just curious, what do you mean by "run from a text file"? Are your refering to the ability to say "perl mycode.pl"? Is there any case where an interpeted low-level language isn't run in this fashion?
        For example, back in the day your could run from a DOS command promt "gwbasic mycode.bas".
        Or are your refering to the ability to put for example "#!/bin/perl" at the top of a script and run the script directly? Because the that is a function of the OS, not the language (i.e, if gwbasic was available for unix y
        • So your argument is that a non-scripting language is one where the runtime is too dumb to figure out which source files need to be compiled to bytecode or interpreted before execution?

          I like it!
        • If you say "perl mycode.pl", mycode.pl is still a text file.

          If you have file with "#!/bin/perl" at the top it is still a text file if you run it directly.

          Doesn't matter how you call it, it is still a text file.

          Yes, PERL is a scripting language.
          • Then what about interpreted Basic or Pascal? Both of these can be run the same way. Keep in mind I'm refering to the language, not the implimentation.
            Of course, some will argue that Basic is a scripting language (or not a language at all), but I won't go there :-)
            Also, even though Pascal is usually compiled, it used to exist primarily as an interpreted language.
            I do agree that Perl is a scripting language, I just can't figure out why (since a perl script doesn't interact "control" another program), wherea
            • As he said already, "Doesn't matter how you call it, it is still a text file."

              There's even a project out there to run C code as a script. In that case, it would be a script written in C. A script is a text file, a program is a compiled file, that's all there is to it.
              • Nope. C isn't a scripting language. Any language where the first 50 lines of your code are used to invoke obscure rituals cannot, by definition, be a scripting language. perl starts with the #! line, then can get right to: print "Hello, World\n" on the second line.

            • Re:What defines a scripting language? (Score:4, Insightful)

              by FriedTurkey ( 761642 ) on Wednesday March 23, 2005 @07:33PM (#12030061)
              Are you talking about a BASIC program run with MS BASICA or something? That is a text file and a therefore a script.

              Let's assume you are talking about Visual Basic. Yes, like Java, Visual Basic requires a runtime engine to execute. However, C++ and C require calls to the operating system. Try running a C++ program without an operating system and see how well it works. So in reality all progamming languages really require an "interperter" to execute. Maybe OS kernel code is the only real stand alone code.
      • But what if I use py2exe for windows and transform my python program into a windows .exe file? Is python still a scripting language then?
        • No, it is not if produces a compiled program. Kinda like how Visual Basic Script is scripting and Visual Basic is not. Doesn't matter if Visual Basic uses runtime DLLs, it is still a compiled file. VBS uses another set of DLLs but runs from a text file.
      • I would consider any programming language directly run from a text file a scripting language.
        You're confusing "scripting" and "interpreted" (as opposed to compiled). The fact that most scripting languages are intepreted doesn't mean that the two concepts are interchangeable. Most people wouldn't consider BASIC a scripting language.

    • I have often wondered what makes a particular language a "scripting" language v.s. a "real" language.

      I think languages were traditionally classified as "scripting" when their primary use was to control the execution of other executables. A point made by all of the folks in the interview is that languages such as perl, python, and ruby have developed well beyond that to the point where they can compete head-to-head with C, C#, Java, etc. In other words, trying to categorize languages as either "scripti

      • languages were traditionally classified as "scripting" when their primary use was to control the execution of other executables.

        I agree completely.
        In fact, I have never considered Python or Ruby to be scripting languages at all; rather, they are interpreted languages, which is something quite orthogonal to being a scripting language.
        Simlarly, languages like awk are not scripting languages.
        Perl is somewhere in between.

        The one thing that I would add to your definition is that a scripting language is interp

        • How would Perl be in between while Python is not?

          • How would Perl be in between while Python is not?

            I wrote that without really thinking too much.
            Modern Perl is probably not a scripting language, but I'm not familiar enough with it to say so for sure.
            However, the last time that I gave Perl more than a cursory look (in the last millenium), it was using UNIX commands (executables) to implement many of its operators.
            For example, I think that it used expr to do RE matching, mv to rename files, etc.
            Perl hid the use of (many of) these commands from the user.
            Tha

    • So for example BASH programming is "scripting" since most of what you do is items that would normally be done at the command line.

      Yes, but BASH is a manly scripting language, where as...

    • Re:What defines a scripting language? (Score:4, Informative)

      by Scott7477 ( 785439 ) on Thursday March 24, 2005 @12:25AM (#12032444) Homepage Journal
      In the article, van Rossum defines a scripting language as one that lacks compile time checking. Pall includes as part of the definition the fact that in these languages memory management is handled
      by the interpreter.

      Hobbs refers the interview reader to a whitepaper which defines scripting languages as follows:

      "There is a category of programming languages which share the properties of being high-level, dynamically typed and open source. These languages have been referred to in the past by some
      as "scripting languages," and by others as "general-purpose programming languages". Neither moniker accurately represents the true strengths of these languages. We propose the term dynamic languages as a compact term which evokes both the technical strengths of the languages and the social strengths of their communities of contributors and users."

      One statement that Pall makes is great: "As more programming is done with scripting languages, doing memory management yourself, or implementing yet another LZW-based compression library will be seen as a risky proposition when deadlines approach."

      I totally agree with this; given that an interpreter manages memory decently, why reinvent the wheel? It is like building your own spark plugs from scratch when you want to do a tune up on your car.
      • given that an interpreter manages memory decently, why reinvent the wheel?

        I don't want to dispute your point, as it does make sense. But it suddenly dawned on me that this particular memory management argument is being brought up so much that it's becoming sterile. To take your car analogy one step further, imagine that certain transmission advocates had been continually arguing for two decades that "given that automatic transmissions prevent the grinding of gears, why use a stick shift?"

        Or let's use are
      • Hobbs refers the interview reader to a whitepaper which defines scripting languages as follows: "There is a category of programming languages which share the properties of being high-level, dynamically typed and open source ..."

        This is cool, the article author just eliminated one very commonly used scripting language by require it to be open source : Visual Basic.

        Many widely used Microsoft applications has a scripting interface via Automation, and guess what, you can use Visual Basic for this! In gen

  • Scripting languages will always have a place , Its a simple case of the right tool for the job.
    As a sysadmin most of my Programming is done in either ruby(im difrent) , shell(bash or ksh) or perl. Using C for most of the things i have to automate is as i said "Taking a sledge hammer to a penut" , It would be total overkill and waste my time and the systems and it would be more error prone .If i do have a larger project that requires a bit more power then i can prototype it in perl or shell then easily transcribe it to C .
    Scripting will always be an important part of my work , and with the increasing power and decresing price of computer equipment over the last few years , it has become viable to program many many things in languages such as python , things which would not so long ago, would have requierd the power of C/++.
    Scripting is in a fine state , and will continue to fill its end of the market , just as compiled languages will always have their place

  • Another cool article about Tcl (Score:5, Informative)

    by DavidNWelton ( 142216 ) on Wednesday March 23, 2005 @05:07PM (#12028349) Homepage
    This article:

    http://www.devsource.com/article2/0,1759,1778148,0 0.asp [devsource.com]

    talks about some of the cool stuff that Tcl does. My favorite thing about the language is that it hits a real sweet spot with its level of abstraction. Python has an event loop now, in Twisted, but Tcl's had the same thing for ages, and it's very easy to use.
    • Look, TCL sucks because:
      1. Richard Stallman says its not a proper programming language
      2. It has a "peculiar syntax" (Stallman again) that makes it too easy to use
      3. It was not invented by GNU and , worse, it is not GPL (it has a BSD like license)
      4. It is not designed for huge applications therefore you should not use it at all
      5. The TCL community is not l33t enough and even help newbies sometimes
      6. Its too easy to get things like text munging and simple GUIs done. What the point if you get everything done in five mi
      • What exactly is the point of bring up an argument from 12 years ago while a very different topic is being discussed with people who mainly don't remember the original issues? The average /.er was in diapers during TECO vs. Lisp. What was it you wanted to achieve here? If you wanted to bring this up again I think you should have provided context.

        Here is an example of one of Stallman's critiques of TCL. Not sure if it is still valid or not but it isn't some nonsense issues

        Tcl also has some serious des
        1. 6. Its too easy to get things like text munging and simple GUIs done. What the point if you get everything done in five minutes

        Easy to start. Hard to debug and maintain. I'm forced to use and repair a PBH's idea of an ideal app daily...and I don't have time to get rid of it by re-doing it in Java or Python. I estimate that about 1/4 of my day is shot because of this monster.

        The reason why the PBH dictated TCL? He's a TCL wiz! The initial developer wasn't; he was a manager. The specialists mainta

  • Developer productivity vs. CPU productivity (Score:5, Insightful)

    by G4from128k ( 686170 ) on Wednesday March 23, 2005 @05:11PM (#12028402)
    For projects below a certain complexity level, I've always found scripting languages to be more productive for the programmer (very fast edit-run-debug cycles) even if they are less efficient for the CPU. And with the advent of JIT compilers, the efficiency of scripting is much improved.

    Given the low-cost of fast CPUs and high-cost of programmers, I'd rather waste CPU cycles than waste developer labor.

  • Experience of a newbie... (Score:3, Informative)

    by CarlinWithers ( 861335 ) on Wednesday March 23, 2005 @05:12PM (#12028413)
    When it comes to programming I know very little. My background is mostly in electronics and as a computer service tech. But I'd have to say I love scripting languages.

    I have a final project in my computer engineering diploma in which we are trying to monitor and control a few security devices over the web. The focus is about split equally between design of a PCB w/ microcontroller and getting the code written. Since my only formal training was in C, and at first I considered using C for the majority of the programming. However after some research I stumbled upon scripting languages.

    The result is that instead of a cumbersome 1000 line C program which would be a huge time sink, I have several small C programs connected with script. I'm using a combination of Bash script, PERL, and Java. I had to learn the basics of each but in the end that was faster and easy to debug. The time I saved went into more hardware hacking and making sure that the electronics portion worked better. In the end it made for a project that was much more fun.

    • I must say that this is the correct way to think about it , If it works and it works well then why switch to C for the job.
      "Right tool for the job" is an important motif for efficent workmanship
    • Instead of a single 1000 line C program, you have a basket of C programs and a basket of programs in different "scripting" languages... And this is better than a single C program?
      • It's entirely possible that a small number of individual problems is easier to maintain than one large one that does the same thing. In this case, it might be easier to do the coordination between the C programs in $SCRIPTING_LANG than it would be in C, if for no other reason than it might be easier to write and maintain the coordination script in $SCRIPTING_LANG than C. If the C programs do sufficiently small and simple tasks, but the coordination is easier to code in $SCRIPTING_LANG there definitely cou
      • Yes. Consider having multiple programs like UNIX's "cat", "sort", "uniq", "sed", and "awk" tied together with shell scripts, instead of one generalized reporting program that tries to do everything for everyone.
      • Perhaps in this instance it's overkill, but the practice of breaking up a program into separate components increases security and maintainability.

        Dan Bernstein [cr.yp.to] is a proponent of this approach, as can be seen by looking at the approach taken in his programs such as Qmail [cachefly.net].

      • Instead of a single 1000 line C program, you have a basket of C programs and a basket of programs in different "scripting" languages... And this is better than a single C program?

        For what the original poster outlined, I'm certain that's the case.

        The core idea is "modular programming". There are a whole raft of advantages. And a large body thinking to support it.

        UN*X is built on this idea. Typical development cycle (see "the unix programming environment)...
        1) mock it up in shell
        2) redo it
        3) Use C to spe

        • I don't see the issue as being modular programming vs Big Ball of Mud. And there is no reason any particular shell script cannot be entirely written in C -- it is all the same Unix utilities and libraries that are function calls in C.

          Why don't we write the whole thing in C? Well, the shell allows us to write quickly and hack around while the C approach has an edit-compile-link-test loop. Why don't we write the whole thing in shell or Perl or whatever? Because we need to optimize the slow parts.

          So a

  • I wish i could find a good scripting language like python and perl where the interpreter (and standard libraries) are distributed as a single executable file. CGIpython comes very close, but unfortunately it doesnt work in interactive mode (at least not the windows version). Oh well....
  • Those basterds ignored us again!! (no I didn't seriously expect to be noticed).

    • Re:Centum (Score:1, Insightful)

      by Anonymous Coward
      You notice that all popular scripting languages are cross platform? Maybe, just maybe, that's why nobody wants to look at yours.
      • You notice that all popular scripting languages are cross platform? Maybe, just maybe, that's why nobody wants to look at yours.

        Yeah like VB that is waaay cross platform. Besides all projects start on one platform. If you care why dont you stop bitching and pitch in and help us port it.
        • Well, we already have Common Lisp on multiple platforms. Unlike Centum, CL is intended to be fast. It doesn't make you throw all the real logic in DLLs to be fast.

          And fix the rendering of the homepage in Firefox while you're at it.

  • I hate dynamic languages (Score:5, Interesting)

    by Anm ( 18575 ) on Wednesday March 23, 2005 @07:30PM (#12030036)
    I've said it before, and I'll say it again.. I hate dynamically typed languages. Just to clarify, this isn't about interpretted versus compiled languages. In fact I love high-level interrupted languages, with syntactic sugar to make my life easier and the ability to edit code during execution. But dynamically typed languages have a serious problem.

    Lets say you have to added a feature to the following function:

    updateCustomerAccount( customer, newInfo )

    Looks nice, with very descriptive function name and parameters. But it isn't. Is customer a string name, a an accountId, or a data structure? Does it return anything (success or failure code)? And a little more debatable, does it throw any errors.

    The usual cases are:
    • You wrote it. Great for when you've just been working on it, but not so great if you're coming back to it after a while or are juggling multiple similar projects.
    • Read the docs. Unfortunately, docs and code regularly get out of sync unless every single member of your team is very tedious to such details. This is especially true of internal APIs. Besides, if you now require such tedious attention to detail at every check in (as opposed to public release where your API docs better be correct), haven't you lost most of the supposed benefits of the script/high level language?
    • Ask the author. Brings programmer out of the code, and not very useful when its more than just down the hall. For distributed development like OSS, email is a slow solution.
    • Use the source. Again, brings the programmer out of their current objective, and this can often be tedious and error prone. That said, there is always a case where this is necessary/useful/insightful.

    But even if you can always rely on one of these solutions, you're missing out on the beauty of statically typed languages: IDEs. By formally typing objects in the language grammar, you have not just documented your code to your peers, but to the machine itself. And allowing the machine to reason about your code means it can help you write it. It keeps you in the code, with instant access to API, documentation, and refactoring. Now you have mentally stepped beyond the code into the problem space.

    Anyone who has written Java in a solid IDE like Eclipse can atest to this. I've had I've had people look over my shoulder in amazement as "the computer writes [my] code" for me. Every function appropriate to the context (and their documentation) usually within 6 keystrokes, without memorization.

    Even the best Python IDEs (strongly typed, but still dynamically typed) pale in comparison to this experience.

    When will the scripting world learn what they're missing?

    Anm

    (For the record, my prefered langauge is Java, but my current work has me doing C, C++, Python, and Perl as necessary. While I haven't worked in it, I assume C# is in the same boat as Java: statically typed, runtime reflexective, dynamically loadable, useful exceptions/stack traces, and large library including the source compiler itself.)
    • I agree with your attitude on dynamic typing. I have just started learning c# and while learning to type everything took me a while, I've found it to just be easier than PHP/Perl and the like because the IDE can suggest the methods, properties and events possible to a given object.

      I love PHP and Perl still and I think for smaller projects it can be easier but its hard to go back now that I've seen the advantages of C#.
      • Honestly, go get a better IDE. WingIDE makes Python programming a lot better. Those of us using Python are very happy for everyone else to be using C#. It makes us seem like demigods of productivity.

        Dynamic typing is awesome. Introspection is awesome. Being able to read your friends' programs without having to run them through "indent" is awesome.

        -dave

    • Re:I hate dynamic languages (Score:4, Interesting)

      by Bastian ( 66383 ) on Wednesday March 23, 2005 @08:21PM (#12030529)
      I agree that this is a serious problem with many dynamically typed languages, but, if I may use the cliche, don't throw the baby out with the bathwater. There are two good solutions to that problem that I can see.

      The first is commenting. (If you can't keep your comments in sync with your code, you have a much bigger problem that you should work out before you even start to argue language paradigms.)

      As for the second, there is nothing in the definition of a dynamically typed language that says you can't include types for function parameters. Personally, I would love to see a dynamcially typed language whose syntax allows for it. In the end, it would just be so much syntactic sugar - a dynamically typed language would just convert the value you pass to the function if it doesn't match the type. However, it would force a higher minimum for readability in code, and it would provide a mechanism for having a -Wall style compiler option for giving warnings about type mismatches. (And before anybody complains, yes, there would be a generic type for functions and data structures that you really do want to be able to handle everything.)

      Really, I think the whole reason why this hasn't happened in any popular scripting languages is becuase the popular scripting languages are designed for very small projects, where you really don't get that much benefit from such a feature. Plus, in my experience, programs written in dynamically typed languages do tend to be better commented. It's a lot harder to escape when you're dealing with a class of languages that tends to be rather on the terse side of things.
      • ...don't throw the baby out with the bathwater.

        When a feature because so predominant that it not only qualifies as a key point in the defintion of the class, but becomes
        • the

        key feature that names the class, it takes a fundamental distinction. I've tried to make myself as clear as possible given the situation. I'd jump at Python if it was staticly typed and had an eclipse editor plugin. That said, my ideal language does not exist yet and I can't offer counter examples to clarify further (although I'm

        • First, the problem isn't limited to function parameters. It's just the example I used. I think the issues are equally present in typing class/struct members and collection values.

          I'll follow your new example. Why don't we allow for casting suggestions on struct or class members as well? We can take this as far as we want. I it's just documentation sugar and a debugging aid.

          Secondly... you want to make programmers go through the effort of naming their types, but you're not going to enforce them? So de

      • Re:I hate dynamic languages (Score:1, Interesting)

        by Anonymous Coward
        Common Lisp is dynamically typed, but with optionally enforceable type annotations and static-style type inferencing in good compilers.

    • Re:I hate dynamic languages (Score:5, Insightful)

      by chris_mahan ( 256577 ) <chris.mahan@gmail.com> on Wednesday March 23, 2005 @08:35PM (#12030705) Homepage
      >Lets say you have to added a feature to the following function:
      >
      > updateCustomerAccount( customer, newInfo )
      >
      >Looks nice, with very descriptive function name and parameters. But it isn't. Is customer a string name, a an accountId, or a data structure? Does it return anything (success or failure code)? And a little more debatable, does it throw any errors.

      Ah. is customer an object? is the new info an object?

      is it smart-merging "newInfo" to "customer"?

      I can come up with a bunch of things that might affect how one uses this function that would not be infomationalized by the addition of types:

      is it accessing an outside system, such as a database?

      is it asynch?

      Does it assume security of the user? In the Customer update log, what is the name of the person who entered the newInfo?

      Is the newInfo an xml document with inbedded base64 pdf? (i've seen in, in mortgage systems)

      Does it notify a third-party in case of failure, logging to the logger, and returning a "pending verification" semi-error code?

      Does it allow for customer to be empty, and if so, does it create a new customer?

      Does it allow either to be empty, thereby creating a new customer with blank, or default information?

      if the newInfo contains a dataset with as-yet unknown fields, is the system desinged to automatically add the fields as xml tags in the customer xml storage?

      Is the previous information in the customer file store elsewhere? as in a change log?

      All functions need a solid API. Since you're going to have an API, you might as well put the type handling in it.

      If a programmer can't be bothered to keep the API docs updated, he is not staying on my team.

      To some questions, the answer is Python.

    • Re:I hate dynamic languages (Score:4, Interesting)

      by cratermoon ( 765155 ) on Wednesday March 23, 2005 @09:30PM (#12031199) Homepage
      • Use the source. Again, brings the programmer out of their current objective, and this can often be tedious and error prone. That said, there is always a case where this is necessary/useful/insightful.

      If reading source code takes you out of your current objective, you have a write-only view of programming, and that's a problem. Take a look at http://www.spinellis.gr/codereading/

      • If reading source code takes you out of your current objective, you have a write-only view of programming, and that's a problem

        Or it could be that you're reading code which isn't in your program flow. Which means you need to hold more in memory.

    • Re:I hate dynamic languages (Score:5, Interesting)

      by p3d0 ( 42270 ) on Thursday March 24, 2005 @01:44AM (#12032897)
      If the information you're missing by omitting type annotations matters to you, then don't use a dynamic language. However, dynamic languages are good for prototypes, and for simple systems. They scale downward further than statically-typed languages. I use them for fun hobby programming, but (for the reasons you mentioned) I don't use them much for professional work.

      I'll give you a pathological example. Consider the Hello World program written in bash (a dynamic language) and Java (a static one). Java looks like this:

      public class Hello {
      public static void main(String[] args){ System.out.println("Hello, world"); }
      }
      Bash looks like this:
      echo Hello, world
      This isn't really a fair comparison per se, but hopefully it illustrates my point regarding the complexity of the problem versus the effort required to code the solution. On the one extreme, you have the "static" languages designed for coding entire "systems programming products" (to borrow a term from Fred Brooks). Of these, the good ones (eg. Eiffel, with its superb multiple inheritance facilities) scale up well to large systems, so the asymptotic slope of the complexity-effort curve is small. However, that curve doesn't cross the origin; that is, as the problem becomes trivially simple, the code required to express the solution reaches some fixed minimum size. In the case of Java, for instance, every program must declare a class with one public static void method taking an array of strings as an argument. That's why nobody uses Java as a command shell.

      On the other extreme, you have shell languages. They do indeed intersect the origin of the complexity-effort curve: that is, it is possible to write a two-character program that does something very simple, such as "cd" or "fg" in bash. If you allow aliases, or UNIX commands like "w", you can write meaningful one-character programs. (This is impossible in Java, no matter what definitions or libraries you presuppose.) However, the slope of the complexity-effort curve is high, and after a program gets larger than a few hundred lines of code, bash becomes almost unusably awkward.

      In between, you have "dynamic" languages like Python. Its curve doesn't hit the origin, and its asymptote's slope is higher than Java's, but there is a sizeable range of programs for which a Python solution requires less effort (at least for me) than bash or Java.

      So, as many others have said, it pays to have a number of tools in your toolchest.

      • In the case of Java, for instance, every program must declare a class with one public static void method taking an array of strings as an argument. That's why nobody uses Java as a command shell.

        What's the problem with that?.

        If you allow aliases, or UNIX commands like "w", you can write meaningful one-character programs. (This is impossible in Java, no matter what definitions or libraries you presuppose.)

        Wrong. Aliases has nothing to do with a language. You can alias w=java -jar myapp.jar or whatever

        • In the case of Java, for instance, every program must declare a class with one public static void method taking an array of strings as an argument. That's why nobody uses Java as a command shell.

          What's the problem with that?.

          The problem with that is for extremely simple programs. And by extremely simple, I'm talking about stuff that barely even qualifies as a program, but would be tiresome to type over and over again. Consider, for example, the case of the classic "Hello, World" program, that the GP ga

    • Not too long ago I would have been in complete agreement with you, but recently I've been dabbling extensively (I know that's probably an oxymoron) in Python and I'm not so sure any more. Take the code:

      bar = map( lambda x: x[1], foo )

      Maybe it's possible to do that with static typing, but if so it would add so much grief in making sure all the type related stuff fits together as to be barely worth doing. And it is worth doing.

      So I'm moving toward the conclusion that dynamic typing in and of itself is a
      • Your example has little to do with typing, and a lot to do with closures (function references), and the lambdas that implements them inline. While there is no technical basis, for some reason staticly typed languages rarely get get these great features.

        I'll be the first to admit that even the best statically typed languages have much to learn from the best dynamic languages like Python. Java is barely beginning to learn the value of integrating the most commonly used data structures into the language, he
        • Actually.. I screwed up slightly. The lambda argument does need to be typed. So maybe:
          bars = map( lambda x: x.y, foos )
          needs to become:
          bars = map( lambda Foo x: x.y, foos )
          still pretty minor change to support typing.
      • You can do something about as concise in Nice [sf.net], a statically-typed Java-like language:
        let bar = foo.map(int[] x => x[1]);
      • While your example might not be right, I completely agree with you and can only encourage you to proceed looking into python.
        I've read and worked on relativly big projects in python like zope, and I have come to the conclusion that the arguments for static typing, while valid, might focus on a too small subset of the task of getting a solid program done.
        What I mean is, yes, static typing gives you some guiding, but on the other hand, it seems to have the effect that the developers might "not see the wood fo

    • If you try to write C or Java programs in Python (or other dynamic language) you will have those problems. If you use the language 'The Right Way', it will be much less of a problem.

      For example, why not have updateCustomerAccount throw an exception if you give it something it can't promote to the right type? Admittedly, type checking isn't useless by any means, it's just not fundamentally necessary for writing and testing. Perhaps it could be added to a dynamic language in the form of a type tag that is i

  • From TFA:

    DevSource: Where do you see scripting languages going? Where will scripting be in five years? Do you see it being replaced by compiled languages?

    Thomas: I see a definite trend among the leaders in the industry away from compiled languages and towards dynamic ones. A lot of Java developers, for example, are experimenting with a Ruby web framework called Rails.

    The distinction isn't really compiled languages vs. interpreted languages. All languages are at some point interpreted (given the complexi

    • Re:Something Thomas said I don't understand... (Score:1, Informative)

      by Anonymous Coward
      Your CS professor only discussed simple RISC processor where the control signals are hard-wired to be generated directly from the machine instructions. However many modern processors use microcode to translate the machine instructions to actual control signals. This level of translation is what Thomas is talking about.

    • I think he's referring to the idea of 'microcode'. If you look at older 8 bit CPUs (eg z80, 6809, 6510, etc) - there's a decent link between the bits in the instruction and what the instructions do. Microcode based CPUs, even the 8086/8088, are a little different: each instruction triggers a series of instructions which in turn make the CPU logic do something (latch register X onto databus, add to accumulator, etc..). So, when you execute an instruction on a microcode CPU you're triggering off a series of
      • To clarify this post a bit.

        You feed a modern processor (assuming x86 compatible) x86 assembly, but internally it executes it's own format of operations. During the fetch/decode stage the x86 operations are "translated" into the internal micro-ops format.

        As such one x86 op may correspond to many internal micro-ops. This is done for several reasons, one of the more fundamental being that x86 asm is now a horrible mess that is not suitable to feed into an extremely optimised processor core.
        • one of the more fundamental being that x86 asm is now a horrible mess that is not suitable to feed into an extremely optimised processor core.

          On a similar note, x86 programming model was always a horrible mess that is not suitable to feed into a programmer or, for that matter, a compiler. It really is junk, but it was junk on the day IBM decided to use it. Motorola had much better chips on the market at the time.

          This is why x86 runs so hot and slow: the instruction set, and especially the register set, is

  • IMHO, all languages should be 'scripted' as well as 'compiled'. The same language syntax can be both. Why not use our advanced computational tools to do the grunt work of optimizing functionality? We've automated every other engineering discipline, but can't seem to do that for our own. (I know I'm overstating the argument, handwaving and idealizing - it's a dirty job, but somebody's gotta do it.)

    What I'd like to see: As I enter code in the language, the system does syntax checking and builds the necessary data structures, prompting and possible asking questions about ambiguities and any necessary library functions either not found or not called correctly. In fact, this process might as well be graphical in nature - NeXTstep's Interface Builder perhaps came closest to this in my experience. The code should be runnable immediately, in an interpreted environment - a la Perl/Python/PHP etc.

    Thus language processing system would act as an intelligent assistant, looking over the system as I design and build it and making suggestions. It might even make performance predictions based on its analysis of the code-so-far.

    Once the functionality is complete, I can pass the system to an even smarter optimizing compiler function, which does the necessary things to make it efficient, small, fast, etc. In the process the compiler may ask more questions about how to resolve various issues that didn't come up earlier. Since the functionality is already defined, the compilation has a mostly-known target for functionality. This process can take as long as necessary, perhaps while I go home for dinner; using more heuristics, AI, whatever, to further improve and clean up the system for the defined functionality.

    Except for the AI features, this combined capability is actually old. Back in the Long Ago, Harris computers ran the Vulcan OS, which had a n interactive FORTRAN system. It did line-by-line compiling, doing syntax checking on each line and even running the code. Once your program was complete and ran, the interactive compiler could output correctly-formatted FORTRAN that could be compiled using the standard FORTRAN compiler.

    • What I'd like to see: As I enter code in the language, the system does syntax checking and builds the necessary data structures, prompting and possible asking questions about ambiguities and any necessary library functions either not found or not called correctly. In fact, this process might as well be graphical in nature - NeXTstep's Interface Builder perhaps came closest to this in my experience. The code should be runnable immediately, in an interpreted environment - a la Perl/Python/PHP etc.

      This is

      • Sometime I'll take another look at Squeak, which seems to be the anointed successor to Smalltalk. I have a friend who's been a total fanatic about Smalltalk for many years - it has affected his career in interesting ways. A few months ago he got me interested in its descendant Squeak [squeak.org], because of Alan Croquet [opencroquet.org] 3D system written in Squeak. So far, I've just bounced off when I've tried to do anything with it. I've been doing procedural programming for a long time. I think it was Dykstra who said (approxima

  • When do you use a hand saw, compared to using a power saw? Different carpenters will have different answers. But having both at your command makes you a better craftsperson.

    perhaps it makes you a more capable craftsperson, but just having the tools does not really help. better? maybe, but not necessarily good. it's knowing when to use one over the other that really makes you good.

    that being said, i love perl for quick stuff, i/o and text processing, and lots of other things. php is great for web and i

Slashdot Top Deals

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Close