Is there a language that encourages good coding practices? - programming-languages

While I love PHP I find its biggest weakness is that it allows and even almost encourages programmers to write bad code.
Is there a language that encourages good programming practices? Or, more specifically, a web-related language that encourages good practices.
I'm interested in languages who have either a stated goal of encouraging good programming or are designed in such a way as to encourage good programming.

I think Python have some ideas for good coding practices. At least programs are forced to look the same way.
But don't forget that Larry Wall said:
Real programmers can write assembly code in any language
You'd better think about creating a coding style convention.

This is way too subjective. If by "good programming practices," you mean consistent indentation, then sure, Python works for that. But indentation is something most programmers learn the first time they write a program. I think good programming goes well beyond that.
Over the years, the idea of what is good programming practice has changed. Python, other than the indentation thing, doesn't really excel in any one category. It's not the most object-oriented language around, nor does it (yet) offer full support for functional programming.
Here are some possible definitions of good programming practices, and a representative language for each:
- Pure object oriented design:
SmallTalk was the first real OO language, and in some ways still the purest. Literally everything is a class.
- Pragmatic object oriented design:
Java, for all it's detractors, was a huge step forward in terms of encouraging good programming practices. It is strongly typed, almost everything is a class, and it requires self-documenting class design, to a certain extent (by explicitly listing thrown exceptions, making functions private by default, etc.) Java enforces disciplines that are valuable for large development teams.
- Functional programming
Haskell is often praised as being the most purely functional language around. Assignment is verboten, and side effects are impossible unless your function explicitly asks for them.
- Robust concurrency
Erlang (another language that encourages the functional programming paradigm) is known for its robustness in a concurrent environment. Never having studied or used it, I can't personally vouch for this, but its track-record seems impressive.
- Iterative development
There are a ton of Lisp evangelists out there. They can't all be wrong, can they?
- Quick 'n' dirty
Sometimes you just need a script done quickly. Thank you, Perl. ;)

Well, it depends on what you consider a web language. Smalltalk definitely encourages best practices, and there's even a crazy web framework written in it (Seaside). It's very different and you can still do bad things. You're simply encouraged to do otherwise.
Eiffel's big thing is Design By Contract. It's a nifty organizational requirement that encourages testing and assertions everywhere.
Python is great, but it doesn't really encourage good practices. Well, if indentation is a best practice, then Python definitely enforces it.
Other languages don't really encourage you to do bad things like PHP does. You can also write great (and proper) code in PHP. People often forget that you can disable much of the nastiness in the interpreter (globals, slashes, etc.). You needn't jump ship just because PHP merely entices you to the dark side.

There is No Silver Bullet. Technology will not make a better programmer of you.

PASCAL is one of the programming languages that encourages good programming practices

Short answer? No. But the question uses English-language ideas that don't lend themselves to computer programming. What does "encourage" mean? What is "good programming practice"? Syntax highlighting and auto-indent? Surely any language can do that. Lint-style warnings? Not terribly hard. Style policing? Well, we'd had to admit C if that was the criteria.
Good programming practice arises naturally from good design. It's quite hard for clever coders to write bad code in any language if the design is clean and simple. Conversely bad practice follows from bad design. The tricky part is working out where a design stops being good and starts being bad. This is the #1 question in software design and sadly there is no silver bullet. Those lovely Design Patterns start looking awfully ugly once you have several of them implemented in your app.

This is pretty subjective, but I would have to say Python. Readability counts and there is only one way to do things make the language very easy to work with.
Frameworks can also reinforce good practices. Python's Django framework is based off the "MTV" pattern and lends itself to very friendly code.

I think really what you're looking for is not a programming language that encourages best practices, but an opinionated web development framework.
Ruby on Rails for instance is very opinionated, and "out of the box" gives you a strong indication of how the framework expects you to interact with it - it automatically creates a project structure, and even provides some initial unit tests. Testing is a very integral part of rails development, and you'll find a lot of resources to support BDD, TDD and other good "agile" development practices.
Other frameworks like Django (python) and Seaside (smalltalk) probably have their own conventions, although I'm not personally familiar with them.

I'm going to attract flames and suggest Perl.
'WTF?' you may say. Perl has a reputation as a write only language. It is, when in the hands of people who use it as merely a super-shell language. You can write crap in any language. Perl gives you massive freedom and flexibility. So, in Perl, logically, you have more freedom to write crappier crap.
The freedom and flexibility can also be used in the cause of readability and maintainability.
But how do you learn to produce good code and not crap? In the past the answer was "Experience, and community involvement." Over the last few years, some new tools and resources have arrived to help as well.
Experience
If you write a turd, and have to maintain that turd, you will learn from the experience.
Lovely. How do you avoid writing turds in the first place?
Community
Instead of enforcing arbitrary rules in the language, Perl has cultural norms that help improve code.
Post code on perlmonks without strict and warnings, and you will hear about why you should use them.
Great, so to do a decent job, I need to spend hours reading websites and newsgroups? Well, you're here now. But this is still a sub-optimal solution.
Tools: This is where we hit paydirt -
A few years ago, Perl Best Practices was published. It codified and collected the ideas of many leaders in the Perl community. It provides detailed discussion of the reasoning behind each of the 256 suggested practices. It offers practices, and a way of thinking about the practice of programming.
perltidy is a great reformatter for Perl that promotes code readability by automatically enforcing formatting style.
Perl::Critic and supporting modules provide a highly configurable system for analyzing Perl code. PC goes way beyond basic lint and even refers you to a specific page in Perl Best Practices for each issue it finds, allowing you to improve your code, five levels beyond the syntax check.
Unit testing is a pervasive part of Perl culture. Perl offers great unit testing tools as part of the 5.10 distribution. Additional testing tools are available from CPAN.
Moose is a new object system for Perl 5. It is inspired by the Perl 6 object system. Moose provides advanced object oriented capabilities like roles and traits. Roles and traits provide powerful new ways of handling code composition and reuse beyond what is possible with inheritance, interfaces and mix-ins. Inheritance models an "IS A" relationship. Roles and traits model "DOES". I can't emphasize enough how useful this is.

You can follow good practices in any language.
Yet you can carry out bad practices in any language as well.

As for writing "bad" code...you have to learn not to do that ;)
As for writing "well styled" code - grab a copy of Visual Studio, the ReSharper plugin, and StyleCop. Intellisense and autoformatting (Visual Studio) will help you lay things out nicely, the ReSharper plugin will restructure your code into a "preferred" structure, and StyleCop will help you follow a standard.

If I'm reading the question correctly, what you're looking for is a language where the "easy" thing to do and the "Best practices" thing to do are closely aligned.
If that's the case, what are the "best practices?" Gotta start with that :)
And as a slightly bizarre suggestion, might I suggest LISP or Scheme?

Haskell.
It makes you write pure code separately
It uses a tab syntax, forcing whitespace
The module system allows effortless organization of code

Why are you asking? The question seems to come up a lot after I deal with some nasty code hairball. I spend hours picking apart spaghetti logic that trails through about 6 subroutine levels. Finally track down the niggling error. And my first thought is why can't this be easier?
Code is written for the computer - not humans. It's optimized for the machine. Machines require exact instructions. At that level of detail, the complexity of any code base goes up fast. And that complexity is what typically drives this question.
Programming languages are not intended to control complexity. Programming tools can help you do that. How you write your code matters a lot more than in what language you write your code.
Take a look at literate programming. It controls complexity through organization. I personally like the visual structure provided by the Leo editor.

You might want to read the seaside book to get some ideas on how to DRY web apps.
The elimination of templates, consequent construction of DSLs for html and javascript frameworks (a.o. jQuery, Scriptaculous, Prototype, RaphaelJs) and even css (Phantasia, not in the base distribution), combination with an OODB for persistence (Gemstone) provides a lot of why is the current state of the art in php, java, ruby or c# so much worse?

I can't believe nobody has mentioned Objective-C / Cocoa. You are encouraged throughout to follow MVC patterns, and loose typing allows for some seriously decoupled OO designs.

Of course, this depends on what one thinks are "good practices". Different languages generally try to enforce/encourage their own opinions of what are "good coding practices".
Some examples of good practices that some languages try to encourage are:
Indenting code in logical levels:
If there's 1 practice that pretty much all programmers agree is good practice, it's that different blocks of code should be indented.
For example, consider the following Java code:
static boolean isPrime(final int x) {
if (x % 2 == 0 && x != 2) {
return false;
} else if (x > 1) {
final int MIDWAY = (x-1) / 2;
for (int i = MIDWAY; i > 1; i--) {
if (x % i == 0) {
return false;
}
}
return true;
}
return false;
}
It's considered best practice to indent the code within different scopes (e.g. function body, for block, if block). However, you don't HAVE to indent your code in a consistent manner (or even at all) in most languages. There's nothing stopping me from writing the whole thing without indentation, like this:
static boolean isPrime(final int x) {
if (x % 2 == 0 && x != 2) {
return false;
} else if (x > 1) {
final int MIDWAY = (x-1) / 2;
for (int i = MIDWAY; i > 1; i--) {
if (x % i == 0) {
return false;
}
}
return true;
}
return false;
}
You could even write the whole thing on 1 line if you wanted to! The code will still work, but it'll be a lot less readable.
However, languages that use offside-rule syntax (e.g. Python, Nim) FORCE you to indent your code in a consistent manner. So for example, the following Python code:
def is_prime(x):
if x % 2 == 0 and x != 2:
return False
elif x > 1:
MIDWAY = int((x-1) / 2)
for i in range(MIDWAY, 1, -1):
if x % i == 0:
return False
return True
return False
HAS to be indented. It won't run if it isn't. It can't. I can't write this code without indentation because blocks are determined BY indentation (and not {}, which is what most languages use).
Ok, Python does allow you to be a LITTLE flexible with your indentation. 1-liners can go on the same line, like this:
def is_prime(x):
if x % 2 == 0 and x != 2: return False # This is allowed.
elif x > 1:
MIDWAY = int((x-1) / 2)
for i in range(MIDWAY, 1, -1):
if x % i == 0: return False # So is this
return True
return False
But that's only for 1-liners. Blocks that contain multiple statements (e.g. the elif block) can't be done on 1 line.
Naming constants LIKE_THIS:
A common coding convention is to name constants CAPITALISED_WITH_UNDERSCORES. That's just so you (and other programmers) can distinguish, at a glance, a normal variable from a constant.
Now Ruby doesn't have user-defined constants (sob), but they have something like it: Ruby will give you a warning if you attempt to change a variable named LIKE_THIS. E.g.
my_var = 5 # creating a normal variable
my_var = 42 # this is ok
puts my_var
ANOTHER_VAR = 21 # creating a pseudo-constant
ANOTHER_VAR = 32 # interpreter will complain about this
puts ANOTHER_VAR # Will still work though
This output of this code is:
42
test.rb:5: warning: already initialized constant ANOTHER_VAR
test.rb:4: warning: previous definition of ANOTHER_VAR was here
32
In this way, Ruby encourages (but doesn't force) you to follow the best practice of naming your constants with UPPERCASE_WITH_UNDERSCORES.
Using constants over variables:
Typically, if you create a variable that you only assign to once (maybe it's just to hold an intermediate value, or you just don't need to re-assign to it), that variable should PROBABLY be a constant (e.g. the MIDWAY var in the above Java code; if I don't intend to re-assign to it, why not make that intent explicit to others by making it constant?).
In Rust, variables are immutable (i.e. constant) by default, unless you specify otherwise (which is the opposite of what Java and C++ does). Example Rust code:
let x = 42; // declaring an immutable variable
x = 10; // compiler will give an error; can't reassign to x.
let mut y = 42; // declaring a mutable (i.e. "normal") variable
y = 10; // allowed
In this sense, Rust encourages you to use constants by default, and to really think about when they should be variables (whereas in most other languages you use variables by default and rarely think about when they should be constants).
NOTE: TECHNICALLY immutable variables aren't the same thing as constants in Rust (Rust actually has constants, declared with the const keyword, but those are evaluated at compile-time). But since they act like constants in other languages, I'll call them constants for the purposes of this post.
Apart from those, most languages won't so much encourage you to actively use good practices as they will discourage (or just outright prevent) you from using "bad" practices.
For example, common wisdom says that using goto is bad practice, so most languages don't even have goto(the exceptions being C & C++)!
From here though, opinion tends to differ on what features are considered to be so bad (in terms of encouraging "bad practice") they're worth not having. For example, overuse of break and continue in loops is considered to be bad practice (for similar reasons to goto), so Scala doesn't even have break or continue (well, at least not built in to the language)! The designers of Go thought that exception-handling tended to be abused (i.e. tempted programmers to write convoluted code and treat too many ordinary errors as "exceptional"), so Go doesn't even have exception-handling! Many languages consider code abusing the ++ and -- operators to be tricky and obscure, so they just don't outright have those operators (Rust, Python, Swift 4, etc). Note that there's not as much consensus here of what's considered good and bad practice.
So there you go, a by-no-means-exhaustive list (might add to it in the future) of some languages that try to encourage good coding practices in 1 way or another (or at least what they consider to be good coding practices).

I'd throw C# out there. It encourages good techniques, readable code and provides tools for ensuring your comments are useful and targetted.
They also provide static analysis tools out of the box to make sure the code is good.

to be clear You can write bad code in any language
anyway C# is really good for following good coding practices

C# undoubtedly... good base and constantly improving.

Yes, Python. Many of its design goals are for the stated purpose of encouraging good coding practices. Read the Python tutorial, and the Zen of Python (type "import this" at a Python prompt).

Coding practices are external to a language. You can just about muck up source code in any language and what is a good practice is subjective.
For example, in C# at the function level you can declare any variable using var and the compiler will enforce type safety, however many people don't like var and think it lends itself to making the code harder to decipher. I personally love var especially when the type is mentioned on the right:
E.g.
var firstName = new string();
is better to me than ...
string firstName = new string();
... because why do I need to say string firstName when I know it's a string based on the right hand instantiation? Of course, once again this is subjective.
Standards and using code analysis tools coupled with code reviews can really make a difference though.
Here's a list of good analysis tools:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Assembler fits the bill of "a language where the bad things to do are either actively discourage or just outright difficult" - having your program segfault at runtime is rather discouraging, and writing badly structured web software in assembler would be outright difficult.

I think an aspect of a language / framework that isn't often talked about is the community around it.
I think Rails does a great job of encouraging better practices not only in the technology itself - which is very much focused on good practices eg. creation of unit tests when you generate scaffolding, but in the community which encourages best practices etc

Boo language for the same reasons as Python.
Maybe I'm a bit biased...?

Related

Is Lua a language that a non-developer can learn quickly?

Let's say a tester is to do some programming to create automated tests ... is Lua really easy to learn for someone who is not a developer?
It depends on the particular non-developer in question. Some people will utterly block on any programming language at all. Some will easily grok many languages and basic programming concepts. There is no silver bullet for putting the power of programming in the hands of someone who is untested on it.
That being said, my personal feeling is that Lua is as good of a place to start as any other programming language.
The Lua language has an active and usually novice-friendly community. It has a long history of use on the boundary between non-programmers and programmers. The language reference manual and standard text book are among the best written examples I've seen in my career. The full text of the reference manual is online, and the first edition of Programming in Lua is as well, although the second edition of PiL reflects the differences in the language that happened after PiL was first published and is well worth the investment to purchase.
One of Lua's strengths is the ease with which it can be integrated into an existing system to construct a configuration and scripting interface to an application. That makes the development cost to adopt it relatively low. Its small size makes the impact on an application release remarkably low as well. Thus getting an existing system to the point where it can be scripted enough with Lua to use Lua as a basis for testing will likely be a straightforward task with few hidden obstacles.
Lua is very forgiving which many people associate with "easy". You do not have to enter semi-colons, you do not have to scope variables, you can write all of your functions in the global scope. Of course doing these things only make your life easier when writing. When debugging even a new programmer may soon see why taking these short cuts is not such a good idea.
I also believe that you can write very simple, easy to use APIs in Lua and you could also create very complex APIs, which may involve object oriented concepts (such as the difference between . and :) or functional APIs with closures and passing around functions as function arguments, etc. Whether the user is able to properly use and understand the language to do the task at hand depends largely on the API as much as or more so than the language.
I do believe Lua is an easier language to learn than many others, like Ruby and Python (and obviously Perl). Lua's grammar and syntax are more consistent than Ruby's for instance; in Ruby you have so many reserved keywords, plus all sorts of symbols (curly-brackets for blocks and pipes for local variables etc), plus it gives you too many options (you can either use curly-brackets for blocks, or you can use the keywords do and end to start and end blocks).
I believe that for non-programmers Lua is much easier especially because of the reasons outlined above. As for programmers, I've read many people say this very same thing and I agree: programming in Lua is very pleasant. I believe that's also because of what I said above.
It probably is becausee its very similar to Python:
The number of universities using Python in there introductory Comp Sci courses is probably the highest of any language (empirically through google). Second probably being Java and Scheme.
The number of Python libraries is astronomical. And the number of people that know the language is quite high thus if you hire a new person there is a good chance they have seen the language before.
Ironically I have grown to not like the language so I am not saying this because I am python fan boy.
As long as you clearly explain to the testers the pitfalls that they may face when debugging in LUA it shouldn't be harder than learning the programming basics of any other language.
What goes through my mind is the situation where the tester made a typo and wrote a different, yet almost unnoticeable, name for a variable. The new variable will be created with the given value but the old variable won't be modified. That sort of thing can be pretty hard to debug when people are not extremely aware of it.
I'm a programmer for more than ten years.
I've learned and used different programming languages.
I've heard about Lua in different occasions, but I've never used it before.
Recently, I decided to learn Lua because our customers are using it.
After spending days on reading the PiL, it turned out for me that Lua is a powerful, flexible, yet sophisticated programming language.
From a software developer point of view, I don't think it's easy for me to be a good coder in Lua in a short time.
But if you just want to 'do something' with Lua, especially if you are from a background of non-programmer, you may feel pleased with Lua, which may be much easier to write some ready-to-use code than some 'traditional' language such as Java, C/C++, Python, etc.

New or not so well-known paradigms, syntax features and behaviours of programming languages?

I've designed some educational programming languages and interpreters for them, but my problem always was that they ended up "normal" and "boring", mostly similar to some kind of existing language (ASM and BASIC).
I find it really hard to come up with new ideas for syntax features, "neat things" and new or very modified programming paradigms for it. I always thought that it was hard to come up with good new things not fun/useless new things for this case.
I wondered if you could help me out with your creativity:
What features in terms of language syntax and built-in functions as well as maybe even new paradigms can I work into my language to keep it useless but more fun, enjoyable, interesting and/or different to program in?
I always thought that it was hard to come up with good new things
You were right. This is why John Backus, Ken Iverson, Niklaus Wirth, Robin Milner, Kristen Nygaard and Ole-Johan Dahl, Alan Kay, and Barbara Liskov all won Turing Awards—they contributed good new ideas to the design of programming languages.
If you want to add a dash of interest to your own designs, these are excellent people to steal from.
Both ASM and BASIC are imperative languages, so you might want to consider features of functional programming languages, especially lambdas and maps. You might also want to consider interesting flows of control, for example, being able to throw an exception and then later, as a result of catching the exception and making a certain call, resume from the point that the exception was thrown (albeit using a modified environment). Also, co-routines, or other forms of language-level parallelism are often interesting.
In addition to Michael's comment on functional languages, look at closures and blocks (like they're done in Objective-C). Those let you treat functions or pieces of code as first-class objects that you can pass around and call on demand. Some cool stuff can be done with that, and it's also shaping up to becoming the paradigm for programming massively multi-core systems.
You could also look into currying, which means binding some of a function's parameters, so you can then use it on fewer arguments. That way, you could create a base-b logarithm function, which you could curry to create functions for the base-2, base-10, etc. logarithm.
And something less functional (as in language): look at Ruby's way of treating everything as an object (even numbers), you can do quite a bit with that. Like an object-oriented runtime with introspection, an interpreter "for free," etc. Implementing OOP stuff is easier than you'd think.
A lot of stuff has been done in the last 30-odd years, don't restrict yourself to 70s-style programming! ;) If you're looking for inspiration, check out Ruby, Python, Scala, Objective-C, JavaScript (read Douglas Crockford's JavaScript: The Good Parts), etc.
The Esolang wiki gives a good sample of the weirds and wonderfuls of all kinds of esoteric programming languages, including many user creations. Perhaps some inspiration for something sane lies therein.
look at Forth. It is something original. Too original.
intercal has plenty of unusual language features B-)
I've always thought it would be neat to apply CSP to a stack based language. Could get pretty interesting.
See Wikipedia: Programming Languages. There are many useful links, especially in the Taxonomies section.
So much of the "new" is really just "forgotten old". I will hold my thoughts on some of the "popular" programming languages of the day.
There are many things that could be explored and active research is being done on some of them. Some of the things I think would be useful are:
real continuations in a non-functional language
here is an attempt to add them on to C++: http://mainisusuallyafunction.blogspot.co.nz/2012/02/continuations-in-c-with-fork.html
languages that let the user create new syntax elements
FORTH and J might be starting points.
Pogoscript is interesting as well because flow control constructs like if/elseif/else and while/wend arten't special can be created in user code.
custom user defined operators actually aren't new: I think Haskell, Nemerle, Kaleidoscope and several others already do this but even that wouldn't be "boring"

What real programming languages are easy to write interpreters for?

What real programming languages are easy to write interpreters for?
"Real" languages for me, are languages you can actually write a small project with, not one of the easy Esoteric programming languages.
(I'm asking because I want to do some hobby project.)
The Metacircular Evaluator in SICP is an exercise for writing a Scheme interpreter in Scheme. It's a common first-year CS project.
It is very easy to write an interpreter for the programming
language Forth (once you know how - but it is well
documented). Forth has been in use for real-world problems
for more than 40 years.
Perhaps it is too easy, but you will learn a lot in the process.
A light-hearted (online) introduction is in
chapter 9 of Leo Brodie's "Starting FORTH".
The original Wirth's Pascal is a good candidate, and often used as a demo in parser generators. Its grammar is LL(1), and otherwise fairly strict, so it's easy to parse. Feature-wise it's pretty limited as well.
You might want to fiddle with it a bit a bit, though - e.g. you might want to ignore pointers, but support first-class strings.
Forth. Okay, now I'm only typing this because I need at least 15 characters in the answer, but the smallest Forth implementations are a couple of KB. It's hard to think of any other language that could have such a small core. Maybe the original McCarthy 1958 Lisp, where the functions were hand compiled.
Scheme, or any lisp variant.
In my college operating systems class we wrote an interpreter for Db (D-flat). It was very simple and well-defined.
I would think a markup syntax language, Liran.
The syntax structure makes for easy parsing since code blocks are clearly delineated between begin and end tags. You could theoretically easily build a level 1 interpreter that parses and runs the code directly.
That said there aren't any markup languages out there that do meaningful things in the context I seem you are aiming at (you may want to write your own). Next best choice would probably languages with minimum functionality and preferably not supporting procedural programming. A language like BASIC should be easy to build a level 1 interpreter for.
Next best thing perhaps is early script languages which didn't offer many syntactic elements and were rather short in complexity. I fail to think of any though.
But perhaps the best option of all is for you to design your own language. The interpreter becomes easier to build because you have a deep knowledge of the language syntax and can rule your own language structure and semantics in the interpreter.
...
The insistence on level 1 interpreter is because you did mention you want it easy.

What is your opinion on the Falcon language?

Falcon is a programming language that supports multiple paradigms like message passing, OO, functional, and yet the code looks nice and clean.
What do you think, does it have a chance to take off and be used as a general purpose programming glue language? Is it worth exploring? What are your impressions so far if you used it in real projects?
I've downloaded it. It's powerful, flexible, Unicode-aware, and in use in real-world situations, namely as the scripting language for AuroraUX.
Falcon is our scripting language of choice. "Simple, fast and powerful programming language, easy to learn and to feel comfortable with, and a scripting engine ready to empower mission-critical multithreaded applications." -- http://www.auroraux.org/index.php/AuroraUX:About
Speaking of Unicode, this is a real Falcon script:
// International class; name and street
class 国際( なまえ, Straße )
// set class name and street address
नाम = なまえ
شَارِع = Straße
// Say who am I!
function 言え!()
>#"I am $(self.नाम) from ",self.شَارِع
end
end
// all the people of the world!
民族 = [ 国際( "高田 Friederich", "台湾" ),
国際( "Smith Σωκράτης", "Cantù" ),
国際( "Stanisław Lec", "południow" ) ]
for garçon in 民族: garçon.言え!()
It currently has a small but active developer community and so it's currently at the state where the cool features are really solidifying. Given that the interpreter is currently almost completely unoptimised, it still runs at a very impressive speed.
I know of someone using for all the scripting in their game (replacing Lua) and as far as I know, they've found it a pleasure to use.
While it looks interesting, and has some cool ideas, I don't see much use in learning it unless it's used in industry and or academia.
The history of programming languages is littered with great languages that have fallen to the way side because no one adopted them.
Their features are however often incorporated into more popular languages.
That said Ruby was created in 1993 and rarely heard of it till it got used in Ruby on Rails. Now it's the next big new shiny thing.
So maybe in 2023 I'll be eating my words, but then again if Falcon is a good language and I need to use it then it should be easy enough to pick it up.
What do you think, does it have a chance to take off and be used as a general purpose programming glue language? no one knows!
Is it worth exploring? I guess any language is worth to take a look at
What are your impressions so far if you used it in real projects? I have not used it
Today a race exists to see who creates the most sofisticated language borrowing syntax among them.
Regarding easy to read programs, we can depart from assembly language (and esoteric languages!), following near english ones (C, Java, PHP and Delphi my favorite) and finally english like ones. For example, COBOL.
¿Do we really need a new language? hard to tell. Java was regarded a curiosity and quickly got strong influence in the industry. Dart on the other hand, promised a lot and still have not heard of nobody using it.
Where will Falcon will be positioned? Only time will tell. Personally, I find it's syntax too sofisticated (and also Java, PHP and C). I have been programming in Pascal for many years (and its variants) and prefer something like:
Writeln('I am ',age,'years old and my zipcode is ',zipcode);
Than C++:
cout << "I am " << age << " years old and my zipcode is " << zipcode;
I guess all programmers have a favorite (or in some cases only one) programming language. That leads to the saying "When the only tool you know is a hammer, all problems look like nails!" (perhaps the same can be said about database engines) How many users create "databases" using worksheets?
So, in conclusion I will explore it to enhace my tool box and have a hammer, screwdriver and even a sextant!

What do people find so appealing about dynamic languages? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
It seems that everybody is jumping on the dynamic, non-compiled bandwagon lately. I've mostly only worked in compiled, static typed languages (C, Java, .Net). The experience I have with dynamic languages is stuff like ASP (Vb Script), JavaScript, and PHP. Using these technologies has left a bad taste in my mouth when thinking about dynamic languages. Things that usually would have been caught by the compiler such as misspelled variable names and assigning an value of the wrong type to a variable don't occur until runtime. And even then, you may not notice an error, as it just creates a new variable, and assigns some default value. I've also never seen intellisense work well in a dynamic language, since, well, variables don't have any explicit type.
What I want to know is, what people find so appealing about dynamic languages? What are the main advantages in terms of things that dynamic languages allow you to do that can't be done, or are difficult to do in compiled languages. It seems to me that we decided a long time ago, that things like uncompiled asp pages throwing runtime exceptions was a bad idea. Why is there is a resurgence of this type of code? And why does it seem to me at least, that Ruby on Rails doesn't really look like anything you couldn't have done with ASP 10 years ago?
I think the reason is that people are used to statically typed languages that have very limited and inexpressive type systems. These are languages like Java, C++, Pascal, etc. Instead of going in the direction of more expressive type systems and better type inference, (as in Haskell, for example, and even SQL to some extent), some people like to just keep all the "type" information in their head (and in their tests) and do away with static typechecking altogether.
What this buys you in the end is unclear. There are many misconceived notions about typechecking, the ones I most commonly come across are these two.
Fallacy: Dynamic languages are less verbose. The misconception is that type information equals type annotation. This is totally untrue. We all know that type annotation is annoying. The machine should be able to figure that stuff out. And in fact, it does in modern compilers. Here is a statically typed QuickSort in two lines of Haskell (from haskell.org):
qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
And here is a dynamically typed QuickSort in LISP (from swisspig.net):
(defun quicksort (lis) (if (null lis) nil
(let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
(append (quicksort (remove-if-not fn r)) (list x)
(quicksort (remove-if fn r))))))
The Haskell example falsifies the hypothesis statically typed, therefore verbose. The LISP example falsifies the hypothesis verbose, therefore statically typed. There is no implication in either direction between typing and verbosity. You can safely put that out of your mind.
Fallacy: Statically typed languages have to be compiled, not interpreted. Again, not true. Many statically typed languages have interpreters. There's the Scala interpreter, The GHCi and Hugs interpreters for Haskell, and of course SQL has been both statically typed and interpreted for longer than I've been alive.
You know, maybe the dynamic crowd just wants freedom to not have to think as carefully about what they're doing. The software might not be correct or robust, but maybe it doesn't have to be.
Personally, I think that those who would give up type safety to purchase a little temporary liberty, deserve neither liberty nor type safety.
Don't forget that you need to write 10x code coverage in unit tests to replace what your compiler does :D
I've been there, done that with dynamic languages, and I see absolutely no advantage.
When reading other people's responses, it seems that there are more or less three arguments for dynamic languages:
1) The code is less verbose.
I don't find this valid. Some dynamic languages are less verbose than some static ones. But F# is statically typed, but the static typing there does not add much, if any, code. It is implicitly typed, though, but that is a different thing.
2) "My favorite dynamic language X has my favorite functional feature Y, so therefore dynamic is better". Don't mix up functional and dynamic (I can't understand why this has to be said).
3) In dynamic languages you can see your results immediately. News: You can do that with C# in Visual Studio (since 2005) too. Just set a breakpoint, run the program in the debugger and modify the program while debbuging. I do this all the time and it works perfectly.
Myself, I'm a strong advocate for static typing, for one primary reason: maintainability. I have a system with a couple 10k lines of JavaScript in it, and any refactoring I want to do will take like half a day since the (non-existent) compiler will not tell me what that variable renaming messed up. And that's code I wrote myself, IMO well structured, too. I wouldn't want the task of being put in charge of an equivalent dynamic system that someone else wrote.
I guess I will be massively downvoted for this, but I'll take the chance.
VBScript sucks, unless you're comparing it to another flavor of VB.
PHP is ok, so long as you keep in mind that it's an overgrown templating language.
Modern Javascript is great. Really. Tons of fun. Just stay away from any scripts tagged "DHTML".
I've never used a language that didn't allow runtime errors. IMHO, that's largely a red-herring: compilers don't catch all typos, nor do they validate intent. Explicit typing is great when you need explicit types, but most of the time, you don't. Search for the questions here on generics or the one about whether or not using unsigned types was a good choice for index variables - much of the time, this stuff just gets in the way, and gives folks knobs to twiddle when they have time on their hands.
But, i haven't really answered your question. Why are dynamic languages appealing? Because after a while, writing code gets dull and you just want to implement the algorithm. You've already sat and worked it all out in pen, diagrammed potential problem scenarios and proved them solvable, and the only thing left to do is code up the twenty lines of implementation... and two hundred lines of boilerplate to make it compile. Then you realize that the type system you work with doesn't reflect what you're actually doing, but someone else's ultra-abstract idea of what you might be doing, and you've long ago abandoned programming for a life of knicknack tweaking so obsessive-compulsive that it would shame even fictional detective Adrian Monk.
That's when you go get plastered start looking seriously at dynamic languages.
I am a full-time .Net programmer fully entrenched in the throes of statically-typed C#. However, I love modern JavaScript.
Generally speaking, I think dynamic languages allow you to express your intent more succinctly than statically typed languages as you spend less time and space defining what the building blocks are of what you are trying to express when in many cases they are self evident.
I think there are multiple classes of dynamic languages, too. I have no desire to go back to writing classic ASP pages in VBScript. To be useful, I think a dynamic language needs to support some sort of collection, list or associative construct at its core so that objects (or what pass for objects) can be expressed and allow you to build more complex constructs. (Maybe we should all just code in LISP ... it's a joke ...)
I think in .Net circles, dynamic languages get a bad rap because they are associated with VBScript and/or JavaScript. VBScript is just a recalled as a nightmare for many of the reasons Kibbee stated -- anybody remember enforcing type in VBScript using CLng to make sure you got enough bits for a 32-bit integer. Also, I think JavaScript is still viewed as the browser language for drop-down menus that is written a different way for all browsers. In that case, the issue is not language, but the various browser object models. What's interesting is that the more C# matures, the more dynamic it starts to look. I love Lambda expressions, anonymous objects and type inference. It feels more like JavaScript everyday.
Here is a statically typed QuickSort in two lines of Haskell (from haskell.org):
qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
And here is a dynamically typed QuickSort in LISP (from swisspig.net):
(defun quicksort (lis) (if (null lis) nil
(let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
(append (quicksort (remove-if-not fn r)) (list x)
(quicksort (remove-if fn r))))))
I think you're biasing things with your choice of language here. Lisp is notoriously paren-heavy. A closer equivelent to Haskell would be Python.
if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])
Python code from here
For me, the advantage of dynamic languages is how much more readable the code becomes due to less code and functional techniques like Ruby's block and Python's list comprehension.
But then I kind of miss the compile time checking (typo does happen) and IDE auto complete. Overall, the lesser amount of code and readability pays off for me.
Another advantage is the usually interpreted/non compiled nature of the language. Change some code and see the result immediately. It's really a time saver during development.
Last but not least, I like the fact that you can fire up a console and try out something you're not sure of, like a class or method that you've never used before and see how it behaves. There are many uses for the console and I'll just leave that for you to figure out.
Your arguments against dynamic languages are perfectly valid. However, consider the following:
Dynamic languages don't need to be compiled: just run them. You can even reload the files at run time without restarting the application in most cases.
Dynamic languages are generally less verbose and more readable: have you ever looked at a given algorithm or program implemented in a static language, then compared it to the Ruby or Python equivalent? In general, you're looking at a reduction in lines of code by a factor of 3. A lot of scaffolding code is unnecessary in dynamic languages, and that means the end result is more readable and more focused on the actual problem at hand.
Don't worry about typing issues: the general approach when programming in dynamic languages is not to worry about typing: most of the time, the right kind of argument will be passed to your methods. And once in a while, someone may use a different kind of argument that just happens to work as well. When things go wrong, your program may be stopped, but this rarely happens if you've done a few tests.
I too found it a bit scary to step away from the safe world of static typing at first, but for me the advantages by far outweigh the disadvantages, and I've never looked back.
I believe that the "new found love" for dynamically-typed languages have less to do with whether statically-typed languages are better or worst - in the absolute sense - than the rise in popularity of certain dynamic languages. Ruby on Rails was obviously a big phenomenon that cause the resurgence of dynamic languages. The thing that made rails so popular and created so many converts from the static camp was mainly: very terse and DRY code and configuration. This is especially true when compared to Java web frameworks which required mountains of XML configuration. Many Java programmers - smart ones too - converted over, and some even evangelized ruby and other dynamic languages. For me, three distinct features allow dynamic languages like Ruby or Python to be more terse:
Minimalist syntax - the big one is that type annotations are not required, but also the the language designer designed the language from the start to be terse
inline function syntax(or the lambda) - the ability to write inline functions and pass them around as variables makes many kinds of code more brief. In particular this is true for list/array operations. The roots of this ideas was obviously - LISP.
Metaprogramming - metaprogramming is a big part of what makes rails tick. It gave rise to a new way of refactoring code that allowed the client code of your library to be much more succinct. This also originate from LISP.
All three of these features are not exclusive to dynamic languages, but they certainly are not present in the popular static languages of today: Java and C#. You might argue C# has #2 in delegates, but I would argue that it's not widely used at all - such as with list operations.
As for more advanced static languages... Haskell is a wonderful language, it has #1 and #2, and although it doesn't have #3, it's type system is so flexible that you will probably not find the lack of meta to be limiting. I believe you can do metaprogramming in OCaml at compile time with a language extension. Scala is a very recent addition and is very promising. F# for the .NET camp. But, users of these languages are in the minority, and so they didn't really contribute to this change in the programming languages landscape. In fact, I very much believe the popularity of Ruby affected the popularity of languages like Haskell, OCaml, Scala, and F# in a positive way, in addition to the other dynamic languages.
Personally, I think it's just that most of the "dynamic" languages you have used just happen to be poor examples of languages in general.
I am way more productive in Python than in C or Java, and not just because you have to do the edit-compile-link-run dance. I'm getting more productive in Objective-C, but that's probably more due to the framework.
Needless to say, I am more productive in any of these languages than PHP. Hell, I'd rather code in Scheme or Prolog than PHP. (But lately I've actually been doing more Prolog than anything else, so take that with a grain of salt!)
My appreciation for dynamic languages is very much tied to how functional they are. Python's list comprehensions, Ruby's closures, and JavaScript's prototyped objects are all very appealing facets of those languages. All also feature first-class functions--something I can't see living without ever again.
I wouldn't categorize PHP and VB (script) in the same way. To me, those are mostly imperative languages with all of the dynamic-typing drawbacks that you suggest.
Sure, you don't get the same level of compile-time checks (since there ain't a compile time), but I would expect static syntax-checking tools to evolve over time to at least partially address that issue.
One of the advantages pointed out for dynamic languages is to just be able to change the code and continue running. No need to recompile. In VS.Net 2008, when debugging, you can actually change the code, and continue running, without a recompile. With advances in compilers and IDEs, is it possible that this and other advantages of using dynamic languages will go away.
Ah, I didn't see this topic when I posted similar question
Aside from good features the rest of the folks mentioned here about dynamic languages, I think everybody forget one, the most basic thing: metaprogramming.
Programming the program.
Its pretty hard to do in compiled languages, generally, take for example .Net. To make it work you have to make all kind of mambo jumbo and it usualy ends with code that runs around 100 times slower.
Most dynamic languages have a way to do metaprogramming and that is something that keeps me there - ability to create any kind of code in memory and perfectly integrate it into my applicaiton.
For instance to create calculator in Lua, all I have to do is:
print( loadstring( "return " .. io.read() )() )
Now, try to do that in .Net.
My main reason for liking dynamic (typed, since that seems to be the focus of the thread) languages is that the ones I've used (in a work environment) are far superior to the non-dynamic languages I've used. C, C++, Java, etc... they're all horrible languages for getting actual work done in. I'd love to see an implicitly typed language that's as natural to program in as many of the dynamically typed ones.
That being said, there's certain constructs that are just amazing in dynamically typed languages. For example, in Tcl
lindex $mylist end-2
The fact that you pass in "end-2" to indicate the index you want is incredibly concise and obvious to the reader. I have yet to see a statically typed language that accomplishes such.
I think this kind of argument is a bit stupid: "Things that usually would have been caught by the compiler such as misspelled variable names and assigning an value of the wrong type to a variable don't occur until runtime" yes thats right as a PHP developer I don't see things like mistyped variables until runtime, BUT runtime is step 2 for me, in C++ (Which is the only compiled language I have any experience) it is step 3, after linking, and compiling.
Not to mention that it takes all of a few seconds after I hit save to when my code is ready to run, unlike in compiled languages where it can take literally hours. I'm sorry if this sounds a bit angry, but I'm kind of tired of people treating me as a second rate programmer because I don't have to compile my code.
The argument is more complex than this (read Yegge's article "Is Weak Typing Strong Enough" for an interesting overview).
Dynamic languages don't necessarily lack error checking either - C#'s type inference is possibly one example. In the same way, C and C++ have terrible compile checks and they are statically typed.
The main advantages of dynamic languages are a) capability (which doesn't necessarily have to be used all the time) and b) Boyd's Law of Iteration.
The latter reason is massive.
Although I'm not a big fan of Ruby yet, I find dynamic languages to be really wonderful and powerful tools.
The idea that there is no type checking and variable declaration is not too big an issue really. Admittedly, you can't catch these errors until run time, but for experienced developers this is not really an issue, and when you do make mistakes, they're usually easily fixed.
It also forces novices to read what they're writing more carefully. I know learning PHP taught me to be more attentive to what I was actually typing, which has improved my programming even in compiled languages.
Good IDEs will give enough intellisense for you to know whether a variable has been "declared" and they also try to do some type inference for you so that you can tell what a variable is.
The power of what can be done with dynamic languages is really what makes them so much fun to work with in my opinion. Sure, you could do the same things in a compiled language, but it would take more code. Languages like Python and PHP let you develop in less time and get a functional codebase faster most of the time.
And for the record, I'm a full-time .NET developer, and I love compiled languages. I only use dynamic languages in my free time to learn more about them and better myself as a developer..
I think that we need the different types of languages depending on what we are trying to achieve, or solve with them. If we want an application that creates, retrieves, updates and deletes records from the database over the internet, we are better off doing it with one line of ROR code (using the scaffold) than writing it from scratch in a statically typed language. Using dynamic languages frees up the minds from wondering about
which variable has which type
how to grow a string dynamically as needs be
how to write code so that if i change type of one variable, i dont have to rewrite all the function that interact with it
to problems that are closer to business needs like
data is saving/updating etc in the database, how do i use it to drive traffic to my site
Anyway, one advantage of loosely typed languages is that we dont really care what type it is, if it behaves like what it is supposed to. That is the reason we have duck-typing in dynamically typed languages. it is a great feature and i can use the same variable names to store different types of data as the need arises. also, statically typed languages force you to think like a machine (how does the compiler interact with your code, etc etc) whereas dynamically typed languages, especially ruby/ror, force the machine to think like a human.
These are some of the arguments i use to justify my job and experience in dynamic languages!
I think both styles have their strengths. This either/or thinking is kind of crippling to our community in my opinion. I've worked in architectures that were statically-typed from top to bottom and it was fine. My favorite architecture is for dynamically-typed at the UI level and statically-typed at the functional level. This also encourages a language barrier that enforces the separation of UI and function.
To be a cynic, it may be simply that dynamic languages allow the developer to be lazier and to get things done knowing less about the fundamentals of computing. Whether this is a good or bad thing is up to the reader :)
FWIW, Compiling on most applications shouldn't take hours. I have worked with applications that are between 200-500k lines that take minutes to compile. Certainly not hours.
I prefer compiled languages myself. I feel as though the debugging tools (in my experience, which might not be true for everything) are better and the IDE tools are better.
I like being able to attach my Visual Studio to a running process. Can other IDEs do that? Maybe, but I don't know about them. I have been doing some PHP development work lately and to be honest it isn't all that bad. However, I much prefer C# and the VS IDE. I feel like I work faster and debug problems faster.
So maybe it is more a toolset thing for me than the dynamic/static language issue?
One last comment... if you are developing with a local server saving is faster than compiling, but often times I don't have access to everything on my local machine. Databases and fileshares live elsewhere. It is easier to FTP to the web server and then run my PHP code only to find the error and have to fix and re-ftp.
Productivity in a certain context. But that is just one environment I know, compared to some others I know or have seen used.
Smalltalk on Squeak/Pharo with Seaside is a much more effective and efficient web platform than ASP.Net(/MVC), RoR or Wicket, for complex applications. Until you need to interface with something that has libraries in one of those but not smalltalk.
Misspelled variable names are red in the IDE, IntelliSense works but is not as specific. Run-time errors on webpages are not an issue but a feature, one click to bring up the debugger, one click to my IDE, fix the bug in the debugger, save, continue. For simple bugs, the round-trip time for this cycle is less than 20 seconds.
Dynamic Languages Strike Back
http://www.youtube.com/watch?v=tz-Bb-D6teE
A talk discussing Dynamic Languages, what some of the positives are, and how many of the negatives aren't really true.
Because I consider stupid having to declare the type of the box.
The type stays with the entity, not with the container. Static typing had a sense when the type of the box had a direct consequence on how the bits in memory were interpreted.
If you take a look at the design patterns in the GoF, you will realize that a good part of them are there just to fight with the static nature of the language, and they have no reason whatsoever to exist in a dynamic language.
Also, I'm tired of having to write stuff like MyFancyObjectInterface f = new MyFancyObject(). DRY principle anyone ?
Put yourself in the place of a brand new programmer selecting a language to start out with, who doesn't care about dynamic versus staic versus lambdas versus this versus that etc.; which language would YOU choose?
C#
using System;
class MyProgram
{
public static void Main(string[] args)
{
foreach (string s in args)
{
Console.WriteLine(s);
}
}
}
Lua:
function printStuff(args)
for key,value in pairs(args) do
print value .. " "
end
end
strings = {
"hello",
"world",
"from lua"
}
printStuff(strings)
This all comes down to partially what's appropriate for the particular goals and what's a common personal preference. (E.G. Is this going to be a huge code base maintained by more people than can conduct a reasonable meeting together? You want type checking.)
The personal part is about trading off some checks and other steps for development and testing speed (while likely giving up some cpu performance). There's some people for which this is liberating and a performance boost, and there's some for which this is quite the opposite, and yes it does sort of depend on the particular flavor of your language too. I mean no one here is saying Java rocks for speedy, terse development, or that PHP is a solid language where you'll rarely make a hard to spot typo.
I have love for both static and dynamic languages. Every project that I've been involved in since about 2002 has been a C/C++ application with an embedded Python interpret. This gives me the best of both worlds:
The components and frameworks that make up the application are, for a given release of an application, immutable. They must also be very stable, and hence, well tested. A Statically typed language is the right choice for building these parts.
The wiring up of components, loading of component DLLs, artwork, most of the GUI, etc... can vary greatly (say, to customise the application for a client) with no need to change any framework or components code. A dynamic language is perfect for this.
I find that the mix of a statically typed language to build the system and a dynamically type language to configure it gives me flexibility, stability and productivity.
To answer the question of "What's with the love of dynamic languages?" For me it's the ability to completely re-wire a system at runtime in any way imaginable. I see the scripting language as "running the show", therefore the executing application may do anything you desire.
I don't have much experience with dynamic languages in general, but the one dynamic language I do know, JavaScript(aka ECMAScript), I absolutely love.
Well, wait, what's the discussion here? Dynamic compilation? Or dynamic typing? JavaScript covers both bases so I guess I'll talk about both:
Dynamic compilation:
To begin, dynamic languages are compiled, the compilation is simply put off until later. And Java and .NET really are compiled twice. Once to their respective intermediate languages, and again, dynamically, to machine code.
But when compilation is put off you can see results faster. That's one advantage. I do enjoy simply saving the file and seeing my program in action fairly quick.
Another advantage is that you can write and compile code at runtime. Whether this is possible in statically compiled code, I don't know. I imagine it must be, since whatever compiles JavaScript is ultimately machine code and statically compiled. But in a dynamic language this is a trivial thing to do. Code can write and run itself. (And I'm pretty sure .NET can do this, but the CIL that .NET compiles to is dynamically compiled on the fly anyways, and it's not so trivial in C#)
Dynamic typing:
I think dynamic typing is more expressive than static typing. Note that I'm using the term expressive informally to say that dynamic typing can say more with less. Here's some JavaScript code:
var Person = {};
Do you know what Person is now? It's a generic dictionary. I can do this:
Person["First_Name"] = "John";
Person["Last_Name"] = "Smith";
But it's also an object. I could refer to any of those "keys" like this:
Person.First_Name
And add any methods I deem necessary:
Person.changeFirstName = function(newName) {
this.First_Name = newName;
};
Sure, there might be problems if newName isn't a string. It won't be caught right away, if ever, but you can check yourself. It's a matter of trading expressive power and flexibility for safety. I don't mind adding code to check types, etc, myself, and I've yet to run into a type bug that gave me much grief (and I know that isn't saying much. It could be a matter of time :) ). I very much enjoy, however, that ability to adapt on the fly.
Nice blog post on the same topic: Python Makes Me Nervous
Method signatures are virtually
useless in Python. In Java, static
typing makes the method signature into
a recipe: it's all the shit you need
to make this method work. Not so in
Python. Here, a method signature will
only tell you one thing: how many
arguments you need to make it work.
Sometimes, it won't even do that, if
you start fucking around with
**kwargs.
Because it's fun fun fun. It's fun to not worry about memory allocation, for one. It's fun not waiting for compilation. etc etc etc
Weakly typed languages allow flexibility in how you manage your data.
I used VHDL last spring for several classes, and I like their method of representing bits/bytes, and how the compiler catches errors if you try to assign a 6-bit bus to a 9-bit bus. I tried to recreate it in C++, and I'm having a fair struggle to neatly get the typing to work smoothly with existing types. Steve Yegge does a very nice job of describing the issues involved with strong type systems, I think.
Regarding verbosity: I find Java and C# to be quite verbose in the large(let's not cherry-pick small algorithms to "prove" a point). And, yes, I've written in both. C++ struggles in the same area as well; VHDL succumbs here.
Parsimony appears to be a virtue of the dynamic languages in general(I present Perl and F# as examples).

Resources