SE Radio 4: Scripting Languages

5 comments

• Actually, there are few TCL scripts on Linux systems unless you go looking for them, but some of the most popular Linux distributions include quite a number of python scripts out of the box – notably Ubuntu and Redhat. Novell does not ship with that much of either TCL or Python though.

  With regard to Python’s “significant whitespace” – you probably owe it to yourself to look at it more seriously. Granted, in early FORTRAN’s, significant whitespace (and the -lack- thereof as well) was a big headache, but that was because it -introduced- problems. In python, the significant whitespace -eliminates- an important class of problems found in most mainstream languages – that of indentation not necessarily reflecting actual code structure, and hence misleading the programmer.

  People don’t freak out about the significant whitespace in Bourne Shell or Haskell or OCaml – why is it ostensibly a big problem (only) in python?

  If you’re automatically generating python code:
  1) It’s a very easy algorithm to indent the stuff
  2) You probably should indent for a curly brace language anyway, even if the code is auto-generated

  Ruby sounds like a fine language, but I don’t think Python should be discounted based on such a trivial canard.

• Wow a great topics. I like this. Thanks for sharing your tips.

  Link Building Service

  One way link – Link Building Service

• I’m surprised that Tcl was not mentioned in the list of scripting languages in use today. I was also surprised that the *extensibility* of scripting languages was not mentioned to make scripting viable for embedded systems development. One could extend (in pure C) cpu intensive portions of an embedded application, developed in Tcl for example. The topic of embedding a scripting engine into a conventional embedded-system/desktop/enterprise application was not discussed either. Tcl was designed from the ground up to be extensible and embeddable. It should not be surprising to note that besides other major projects, Tcl is used as a configuration-shell layer in Cisco routers. The future belongs more and more to high-level abstraction languages that allow extensibility/mutability. Tcl fits the bill in this regard.

• https://micropython.org/ A world of embedded hardware where drivers written in python are first class citizens… Manipulating registers and bit-fields using named tuples instead of kludges of bit-wise operators and magic hex values… Refreshing and amazing… Build more scripting languages I really enjoy using them. 🙂

• This is an episode about about what is not true about scripting languages. The person being interviewed was so biased toward them, that they were almost not willing to admit that anything is true about them, probably because the things that are true about them are mostly negative things, so someone biased toward liking scripting languages would naturally have a hard time finding anything to say about them. Well, if your not going to say anything about them, then stop talking about them.

  The definition of a scripting language is simple, it is a language designed to write scripts in. A script is something you run without having to compile it first. It might get compiled at some point, but that is not a manual step in process for running it. Scripting languages make it possible to take advantage of scripting environments, which make it easy to run scripts. In that sense, scripting languages are focused on being easy to run at the expense of everything else.

  The fact that people have made compilers for some scripting languages does not change the definition or make it a bad one. It does not change the fact that these languages are not primarily designed to be compiled or take full advantage of being compiled.

  They said there is nothing about them that necessarily makes them slower, but that is not true, and is an example of their bias. Scripting languages are slower, full stop. Their very nature makes this true. Take two languages that are designed almost exactly the same, except one is designed to be compiled as the first step toward running it, and the other is not. Which one will run faster? Obviously since these are two different languages we can’t say just yet. But being a scripting language does make that language slower than it would be if it were not a scripting language.

  They also said there is not a really clear distinction between something being statically typed and not statically typed. Once again, their bias toward liking scripting languages is preventing them from seeing the truth. The truth is the exact opposite of that. The difference between statically and dynamic typing is very clear. I guess if they saw the difference clearly they would start to see how flawed scripting languages are for most professional programming, but they don’t want to see this.

  Of course you can take the definition of just about anything and come up with situations where it doesn’t seem to fully apply. That is just the nature of language and speech. We never speak with complete clarity as that would require way too many words and thoughts. Human languages have a certain amount of vagueness to them because that is what makes them the most useful. A definition having a certain amount of ambiguity or edge cases where it does not seem to apply does not make it not a useful definition. Often that makes it more useful because if you were to include all the ins and outs in the definition, it would hard to see the underlying theme, and it would start to be difficult to distinguish it between the definitions of other things.

  Static typing is better when it does not prevent an elegant solution and does not require lots of duplication. Dynamic typing can be better when that is not the case. Refactoring tools are the closet thing to proof that static typing is preferred. Even Uncle Bob, who is a huge proponent of TDD and high code coverage percentages, admits that you can be insanely productive in Java because of the InjelliJ IDE and all the refactoring it can do for you. As soon as you introduce dynamic typing you reduce how helpful tools can be because you reduce what they can know about the code.

  Using scripting languages that primarily support dynamic typing to develop entire professional programs is usually stupid. People mistake easy to start running something with easy to get the project totally completed and working well. The person being interviewed admitted that he has a hard time recommending scripting languages to large teams. Well guess what? The same problems that affect large teams also affect small ones. What is a good or bad idea does not change with the size of the team in this case, what changes is how obvious it is that this is a good or bad idea. Let’s say using a scripting language it takes 6 months to get to a pretty good version 1.0. Let’s say it would have taken 3 months in a more compiled language. This will seem like not such a big deal because it is just an extra 3 months. It might not even be obvious that the scripting language slowed them down. But if you are working on a larger, more ambitious project which requires a larger team, problems like that are harder to ignore or miss. If it takes you 4 years to get to a good version 1.0, and using a compiled language would have reduced that to 2 years, it will be harder to ignore this or not realize it.