Steve Yegge's latest, Code's Worst Enemy, is like all of his posts: rich, rewarding, and ridiculously freaking long. Steve doesn't write often, but when he does, it's a doozy. As I mentioned a year ago, I've started a cottage industry mining Steve's insanely great but I-hope-you-have-an-hour-to-kill writing and condensing it into its shorter form points. So let's begin:
I really wonder why ignorant people always seem to enjoy picking on APL. Before you write about another language, you should really learn enough about it (whatever its character set may be!) to realize that a properly written APL program is in no way a “mish-mash of line nois#8764;R#8712;R#8728;.R)/R#8592; 1#8595;#9075;R1#8595;#9075;R #8728;.#8728;.{{();}{() {…(”");} }{(){…("");}}([]){[]=[]{(),()} #8764;#8764; #8764;#8764;#8764; #8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;#8764;
Not that this applies to Steve’s case, as I respect him, but 500 K of LoC = “my Kingsfield notes on contract law”. All of us have worked with “my-library/framework-is-going-to-be-better” coder guy. What a pain in the ass he is. But, if you write the monstrosity and get away with it, sadly, you have just earned yourself some job security.
I have cleaned house on some of those types of projects and the thing that sucks is the genius 500 coder dude, with his love of complexity and intricacies, has created a cash cow for the unscrupulous sales force to sell consulting services. Most of the business unit folks don’t know what a piece of crap they have, and will shell out more for a 750K library. You can’t fire the genius easily because the code base is so large, the business is tied to it. It sucks as it shows that crappy software with high maintenance.
Staticly typed or dynamic doesn’t matter, level of complexity does.
Anonymous, I was blown away by your first Haskell implementation of quicksort.(1) Impressive!
At that rate of productivity, a programmer’s alloted ten lines of code per day could get a spacecraft to the moon in a month. Or at least somewhere into outer space. Maybe even another dimension.
Wait, wait, a project written in APL would wind up being really short (it might be an unmaintainable mish-mash of line noise, but at least it would be short).
Not sure why everyone is on the ‘its all that static typings fault’ warpath at the moment. There is never a silver-bullet i.e. swapping to a dynamic language (although I do a lot of python and still think it is one of the best languages around). The problem is with the expressiveness of languages - things like meta-programming in ruby - which just happens to be where the dynamic languages are at. And the crufty C-style syntaxes which are present in the mainstream statticly-types languages, C#, Java.
It is possible and static languages are getting better (Scala/Haskell) at providing this power with a nice syntax. I can see a powerful, expressive, statically typed language hitting the mainstream soon - all the power + the checking of the low hanging fruit with typing (it doesn’t pick up a lot of bugs, but it does save on a few tests and prevents ‘silly’ mistakes, which I am not going to say no to).
Again I have to repeat that I am all for the current dynamic languages moving forward, particularly python and ruby, but it is a mistake to identify their positives as benefits of dynamic typing.
Yep, don’t forget the functional languages, especially those with a marvelously strong type system. What can beat the following implementation of quicksort in Haskell
It’s ridicolous that you favor non-typed languages for projects of sizes greater than 100k-LOCs. When you work in greater teams, using typed languages is the only way to survive. Fail early, or you lose in the long way.
typed languages are like well-defined contracts and rules. Without visible rules, you could not master large projects.
Not shorter code is the target, but READABLE code. Understandable code, it’s not the shortest-code-contest.
Ever seen the shortest c-code for a problem? That could not be the right direction, which you show us here.
The type-reflection of c# 3.0 is nice trade-off between ease of writing and the favors of typed languages.
I’ve written my fair share of C++, C#, Java, Javascript, and PHP.
C# is by far the winner, even if it is strongly typed.
At least I know what the hell is going on, unlike in Javascript, where you never know what you’re going to be dealing with.
No documentation? Well, you might have a pretty hard time even finding out what fields exist on the object.
i don’t like the amalgamation between statically typed languages and Java.
yes, its true, statically typed languages are more verbose than dynamically typed ones. this verbosity has a cost. it takes more time to write code and needs some more efforts to maintain. but this cost is also for good: the code is cleaner, often easier to read or, at least, less subject to invisible side-effects (sometimes called programming tricks by script writters). it brings more security.
but not all statically typed languages are lacking the toolbox anyone can await from a real programming language: i mean enumerations, file i/O, and the like… if you are struggling to write a snippet that reads every lines of a text file, you are in deep trouble. either you are not good at programming or your language is badly designed.
for example, reading every lines of a text file in Ada is 6 lines long: 2 for opening/closing, 2 for the loop, 1 for the read, and of course 2 for the declarations. it is not really longer than the equivalent code in python.
i do really think java was badly designed. it is missing a lot of standard features, and bloated by the “all object” methodology used. please, remember that java does not represent all statically typed languages, it is only one example, and not a pretty good one.
also, remember that every language has its prefered domain of use. i will not write my one-liner scripts in Ada, but i won’t write a 500,000 loc software in perl.
Another thing in case of Java is its extremely verbose object and function names. While that is great for a beginner to help understanding (though honestly, to really understand the code they’d have to read the actual documentation and find out all the details anyway) but it’s just annoying if your average function call starts spreading over 3 lines or more.
Also it strongly depends on what you do. I like to do stuff that involves a lot of bit-fiddling, and to me pure C still seems most suitable for that.
The downside is that every time you also have to do something with strings it gets very painful very fast.
As another point I really like C# and Delphi for Gui development, I think they do a superb job there. Except for the fact that unless I restrict myself to .Net 1.1 I haven’t found a way to make the applications work on both Windows and Linux (short of installing and using mono on Windows), so I don’t really have any use for them after all
I love writing code in Ruby.
I hate reading code in Ruby if it’s not my own. Where does it start, where does it end. What’s supposed to go in here? And what comes out there?
I like writing code in C++.
I don’t mind reading code in C++. Even if badly written. Much easier to understand and update or refactor.
I agree with C. Wissing.
You’re rarely wrong Jeff, but when you’re wrong, you’re really wrong.
I think what we have here is the confounding of two issues.
I think the real point here is that it’s hard to write giant complicated programs.
On the border between simple programs and moderate sized programs are programs that become “small and simple” when written in dynamically typed languaged but are effectively “complicated” when written in a statically typed verbose language like C++ or Java. In this small category of programs you may be better off eschewing the strongly typed verbose language.
But you shouldn’t mistake this phenomena for the idea that truely, innately complicated programs would therefore be easier to code and maintain in a dynamically typed non-verbose language. As C. Wissing says, exactly the opposite is the case. In truly large projects, all of the strictures of static typing and verbosity act like a contract which protected the code.
In many ways the analogy with contract is very telling. If you are arranging a quick agreement between friends for a $50 loan you are better off just with a handwritten IOU and avoiding all the legal technical jargon and formalities. But no idiot would take a fifty million dollar loan without a formal, legal, verbose contract.
As much as I’d like to rag on statically typed language, declaring variables has saved me a number of times from when I made a typo in a variable name or used a similarly named variable instead of the correct one.
This is why, when I use Perl, I always have a use strict; near the top of the file, and I really wish other dynamic languages had it.
Yes, it does mean you have to declare variables at the beginning of the scope during which you want them to exist, but without doing that, how is the language going to know what scope said variables should be in?
Insofar as I understand Java’s iteration syntax, the underlying mechanism is the same, just as it is compared to the C# equivalent. “file” is the name of the class; the file(“xxxx.txt”) expression creates a file object, and file objects conform to the iterable protocol; the fancy for syntax directs the compiler to produce the relevant while loop that you’d otherwise have had to write by hand.
I’m not aware of anything in the standard linrary that will allow one to do the same with images, but you could easily write one if you require such a thing, as there’s not really any magic involved.
People agitating for “meta” languages forget they are living in real world with no ideal programmers. I dived into c# linq yesterday, and it was not easy to fully feel and use new concepts.
What to say about functional langs then?
Just dynamic languages are probably okay, but catching errors is harder and even in these exist things average programmer will be really confused with. (i.e. closures are pretty easy ton understand in theory, but in practice there are many complications)
Java and c# made with that in mind. They are not so beautiful as python, but they make programmers write code anyone can understand.
The reason we can now use dynamic languges safely is that Test Driven Development provides the same safety net as the compiler in a static languge, with the massive added benefit of telling the programmer if the application is working functionally.
What an awful and popular mistake. I implore you to retract and apologise before this mythological nonsense is repeated. You need to know what you need to know before debating type systems. http://cdsmith.twu.net/types.html
Case in point:
“yes, its true, statically typed languages are more verbose than dynamically tzyped ones.”
Actually no, I can think of many statically-typed languages that are CONSIDERABLY LESS VERBOSE than all the fanboy (read: popular among the amateur language theorists) dynamic languages that have been discussed so far.
