Transit is a format and set of libraries for conveying values between applications written in different programming languages. This spec describes Transit in order to facilitate its implementation in a wide range of languages.
- Framework for CSS
- Web Framework for C
- Frameworks for Front-end JS
- Web framework for Go
- Web framework for Haskell
- Web framework for Java
- Web framework for Lua
- Web framework for Node.js
- Web framework for Perl
- Web framework for PHP
- Web framework for Python
- Web framework for Ruby
- Web framework for Scala
- Web framework for .NET (C#)
The Archive of Interesting Code is an (ambitious) effort on my part to research, intuit, and code up every interesting algorithm and data structure ever invented. In doing so, I hope both to learn the mathematical techniques that power these technologies and to improve my skills as a programmer.
From Geek and Poke.
Via Geek and Poke.
One of the frequent things that I hear about programmers is that it doesn’t matter which language the person is using and which language you need him to use, because if he is any good he’ll learn and catch up pretty fast. In other words, if you take a decent Java programmer and push him to write PHP code for you, you’ll only have issues for a few days. Or weeks, at most.
I understand the reasons for this statement, but I don’t agree with it. At least not completely.
Firstly, the reasons. They are rather obvoius, but I’d rather stagte them anyway. Computer Science is not specific to any programming language. The concepts and approaches are more or less the same everywhere. Flow control, data structures, and algorithms are not language specific. Each language has its own best practices and recommended variations, but a bubble sort in PHP will be very similar to bubble sort in Java. Then you need some common sense, which is also not laguage bound at all.
Secondly, the disagreement. I think that the Computer Science theory and common sense aren’t the only things that make up a programmer. What makes a lot of difference is experience. Programming languages, in their practical applicatoin, are just collections of software – compilers, linkers, debuggers, libraries, IDEs, etc. Like any other software, programming language software has bugs, undocumented features, and Days When Things Don’t Just Work. It’s the experience with the language that teaches the programmer how to handle the issues of each software piece. And that experience is priceless (almost).
Even if you’d manage to push a Java programmer into writing PHP code, that would a waste of resources. A Java programmer is a Java programmer, not PHP programmer. He will, of course, learn PHP nuances with time, but, he’ll probably lose a part of his priceless (almost) bagage. Sounds a lot like misuse of resources.
Another part of my disagreement is not so much reasoned as emotionalized. I’ve seen a few C and Java developers switch to Perl and PHP for their new positions. Not that I was forcing them to or anything, but they did. And the switch was moslty painful to say the least. Here are some of the areas that I noticed as being hard to comprehend.
Compiling vs. interpreting. Those people who were used to their compilation process were missing something for the first few days. Some needed as much as a week to adopt, even though write-save-reload browser was done a few hundred times a day.
Debugging. There are two major camps here. In the first one are all those people who live in the debugger. They know all the keyboard shortcuts and they have their highlighting customized. In another camp are people of the simpler nature, those who use print() and die() for most of their debugging needs. It seems that most people coming from C and Java prefer the debugger way. Most of the interpretted languages do have either a standalone debugger or a built in debugging tool, but it seems that the majority of interpretted language crowd use the print() and die() approach.
Sigils. If you don’t know what a sigil is, read this Wikipedia page. Because you do know what it is. Many strong type language don’t use any sigils. Most of the loosely typed languages do. Furthermore, when both the language from which you are changing and the language to which you are changing use sigils, chances are there will still be a difference. PHP, for example, uses $ for both scalars and arrays. In Perl though, you’ll get a $ for scalar, @ for array, and % for hash. Perl’s sigils are extremely helpful when figuring out someone else’s code. I remember the pain of having just a $ in PHP, when I was learning it. And I can’t even imagine how confusing it is for people who are used to non-sigilized programming languages.
Types. As already mentioned above, strong typed language programmers can be often confused with the fact that variables can change their type on the fly, and that they don’t even need to be declared before use. Loosely typed language programmers will often complain about the requirement to define their types. Three of the most common questions that I’ve heard regarding this matter were:
- “How do I define an array of elements of a certain type of a certain length?”
- “Is this line a piece of non-sense or does it really do something: $sum += 0; ?”
- “What’s wrong with writing: int amount; amount = 2.5; ?”
There are, of course, more areas than just those – include pathes, include files, OOP, database abstraction, loops (“What the heck is foreach?”), memory management, libraries, and so on and so forth.
Even the list of the resources for each programming language takes time to build. Yes, time. And time is one thing that’s always against us. Everything else we ca handle.
Â Most programmers have successfully compartmentalized their beliefs about code base size. Java programmers are unusually severe offenders but are by no means the only ones. In one compartment, they know big code bases are bad. It only takes grade-school arithmetic to appreciate just how bad they can be. If you have a million lines of code, at 50 lines per “page”, that’s 20,000 pages of code. How long would it take you to read a 20,000-page instruction manual? The effort to simply browse the code base and try to discern its overall structure could take weeks or even months, depending on its density. Significant architectural changes could take months or even years.
As I said, it’s a long piece. But it’s worth every paragraph. Even though some Java programmers might be slightly offended by the article, I’m sure it’s not intentional.