Monday, February 27, 2006

Counter Strike Source Launch Options Location

Compiled vs. Interpreted Languages: Procrastination, fad or trend.

The eternal battle near completion

Several readers of this blog I have questioned my position on languages \u200b\u200blike Java , Perl, PHP , Ruby, ASP , and the latest suite of Microsoft: Visual Studio.Net . Well, it's time to explain my position, which may offend many, perplexing to others and confuse the rest, well, some few people will agree with me.
In short, the key question is: what's better, the scripting language or compiled language? I'll summarize it in one sentence. All languages \u200b\u200bare interpreted.
I know that some (if not most) will say that this is not possible and therefore I will lift at that assertion.
To begin, we define each of the phrases from the standpoint of programming of PC's. Compiled Language

A compiled language is somewhat vague term to refer to a programming language that is typically implemented by a compiler. This means that once written the program, it translates from the source code through a compiler into an executable for a particular platform (eg for Sparc Solaris, Windows NT for Intel, etc.).. (Compiled Language - Wikipedia )

Language Interpreted ... An interpreted language is one in which the instructions are translated or interpreted them one at a time of execution to a machine language or intermediate language or through a virtual machine, typically being about 10 times slower than compiled programs. (Adapted from the definition on Wikipedia)

After the definitions, let's put in Christian terms, or better in computer terms, because not all Christians understand this terminology. A compiled language is that which, in theory, is translated into machine code and generated instructions are interpreted directly by the machine. And an interpreted language is one that is translated into an intermediate (read: non-machine), in which each instruction is interpreted and translated into machine language runtime. In practice, only and counted operating systems that run programs especially for console are in machine code. And before anyone misunderstand, I explain the above.
If we talk about the platform used in the home, understood Micro $ oft Windows, or as to the time of writing of this note, ALL, without exception, languages \u200b\u200bare interpreted or semi-interpreted. Those who know the assembly language the reason I find no problems. In modern operating systems, when you "compile" a program, it translates to a pseudoensamblador or pseudo-machine style, which in turn is interpreted by the "virtual machine" itself or native operating system to process , draw and perform all the instructions properly. Advanced programmers will know that when compiling programs, so you can find is a series of calls to external libraries which perform the tasks required. For UNIX operating systems and other, things do not change much, so do not I go into detail.
But now I go into the field. It is already clear that all programs are interpreted to a greater or lesser degree, the question is now how compilers generate code "more compiled" (forgive the apparent redundancy) than the others. Here I will mix a little personal concept with technical concept. To start I will be direct and mention some languages \u200b\u200bthat are generated, in theory, programs "more compiled" without mentioning the platforms to which they belong (I do miss some compiled languages, not currently used: Fortran, Ada, Algol, COBOL, and others of their time, except BASIC and derivatives):
C compiled language teacher par excellence, except in Visual Studio.Net. I only mention that it is the language in which they were designed the great majority, if not all, modern operating systems.
C + + Some would ponder, why separated C of C + +. Well, it happens that C + + is not compiled as C TAN, especially because almost always used in graphical operating systems, only in console versions is compiled into real machine code, but basically and essentially is compiled to machine code. Pascal
Basically, in all flavors and colors, compiled to native machine code
Delphi, Kylix, Lazarus are highly collected, but not entirely, because they are oriented graphical operating systems, and to a lesser degree are interpreted, but compiled languages \u200b\u200bare considered, because the generated code is native to the target platform.

I mention the best known and most widely used, now they are interpreted languages, which cause so much controversy. more interprestados
BASIC language interpreter par excellence and so far I have knowledge, the oldest, although it was interpreted in principles, then became the milestone of interpreted languages. All derivatives are more or less played, although sometimes, Borland released a compiled BASIC that, in theory (I never checked), to machine code.
JavaScript, VBScript Although this pair, I think that there are no mention of informing the general.
Perl, PHP These languages \u200b\u200bdesigned for web, are interpreted languages \u200b\u200bpar excellence, although intermediate code is compiled at runtime, which speeds up execution. There are also tools to generate close to the machine code for these two languages \u200b\u200band cached content, but ultimately, are still performed.
Batch, Shell Interpreted Languages \u200b\u200bfor OS 's, which is running quite slow, but they usually are so short or perform basic tasks such performance is not noticeable. Java
This language has been quite diversified today, including several of the large modern commercial applications are designed in this language, for example, Zend Studio and Oracle JDeveloper , just to mention two major .
Visual Studio. NET Boom imposition languages \u200b\u200bMicro $ oft. NO program built with the languages \u200b\u200bof the suite or whatever you want to call this package generates machine code and is in fact far from being machine code, or even references to libraries as they would other languages \u200b\u200blike Delphi, C + +, or similar. I'm not against this new methodology for the interpretation of software, but there is a big disadvantage is the very slow implementation of the generated programs and short words explain why (it could do a summary): The language generated is intermediate code which in turn is compiled in time execution, which is interpreted by the Framework. Net, which executes the instructions by the respective calls to operating system libraries. In my personal concept, it too turned to execute a simple instruction to call an OS API. Although the theory is that the compiled program after run-time, stay well, so it is an increase in execution speed, better than I had the opportunity to experience, as interpreted code run einterpretado code, I'm afraid not is very fast to say.

But why so much reluctance to these new technologies?, And what present pros and cons?. It's pretty simple. I'm not against these tercnologías, in fact, are excellent and sooner or later, but sooner or later, will build standards and will be considered as compiled languages.

Advantages of interpreted languages \u200b\u200b

  • Portability: This is the main advantage of this type of language because it can be compiled in and for any platform or operating system.
  • compatibility: as interpreted by the operating system, virtual machine or framework which ensures that the instructions are implemented by the software and hardware.

Disadvantages of interpreted languages \u200b\u200b

  • Speed: It is the most remarkable and which should be evaluated thoroughly to create software with such languages, because it must balance the portability with the speed that is being sacrificed. Unless the benefits of computer equipment are quite high, in which case, one might dismiss this aspect.
  • Portability: it is a disadvantage too. The problem is that today, so all compiled languages, are available for all platforms, so no virtual machines or frameworks, but in the case of Java, has done an excellent job for that matter and I can not complain, exists to almost all platforms, if not all, current. The. NET framework, I regret to say that today, one hundred percent is tested only on Windows, although there are promising projects such portability, but are not yet a fact.

In conclusion, how to act?. It is very difficult. Requirements are evaluated, defined needs, if they do not exceed the hardware to use, well you can continue, otherwise, it is best to think of a compiled language, as interpreted languages \u200b\u200byou require a large amount of resources, especially RAM and processor. Interpreted languages \u200b\u200bshould be exploited to the extent posiblem In a few years or even months and will enter into force (or are they?) the new standard of development.

Thursday, December 1, 2005

How To Say Congratulations Pregnant Couple

not confess to torture by the data: Standards for the design of databases

In Search of a Standard Model Database design

I've always been criticized for keeping my neutral position with regard to design, model selection, patterns, styles and prototypes of all that concerns the programming and databases.
But this time I break a little ice proposing a "standard" for modeling databases.
is not the objective at this time to select a database, which will at a later time.

But first assume that already have a basic knowledge of databases, especially in regards to standards, and has worked at least one database.

is unlikely that anyone has ever wondered why the title, if it is a great background in the world of databases, possibly identify the following quote:

Datamining: The art of torturing the data until they confess

But how could "confess" a poorly organized and structured data? An almost impossible task.
After experimenting with several proposals of different authors, models and "standards", I venture to propose a somewhat risky and daring, and for many counterproductive and abusive, wanting to clarify that my goal is not to say that is a panacea or a statement that must be taken immediately, it is simply a given that everyone will be implemented as deemed. As
develops different entities or tables, with the main problem that I faced is to make / maintenance is the allocation of names to the tables and their fields.
There are several proposals to designate names for tables and fields, which I list below, in addition to presenting the pros and cons of each.
Notation 1:
Rules:
  • The name of the table must have a maximum of 12 characters and all letters must be uppercase. (Ex: Student)
  • The first three letters of each field must refer to the table, followed by a dash of ground or soil (_) and then three characters to indicate the contents of the field, and all characters must be capitalized. (Eg EST_COD, EST_NOM, EST_APE, EST_DIR)
Advantages:
For your time ofrececía main advantage was that due to the limitation that had the MS-DOS and similar files only up to 8 characters guaranteed that the name always would be valid. It never applied to databases on Unix or similar. SQL Code
very short and relatively easy to modify
Disadvantages:
may occur if two fields may have very similar names and complicate the maintenance of the tables
Notation 2:
Rules:
  • All table and field names are capitalized
  • The name of the table should be the least amount of characters and this is all the vowels deleted. There are only two exceptions to this rule. The first if the word starts with a vowel, and the second, when the vowels of last syllable is meaningful or can clarify the word (eg, ESTDNTE)
  • The field names must start with three characters, corresponding to the table where they belong or, in the case of foreign fields, the name of the master table (Ex: EST_CDGO, EST_NMBRE, EST_APLLDO CIU_NCMNTO)
Advantages:
organized tables and fields, where you can define the data source in the case of foreign fields.
Disadvantages:
resulting SQL code extremely complex and confusing, due to the possible similarity between words, they contain no vowels difficult to read and well maintained appropriate database
Basically, these are the notations used or perhaps have been the basis for many others, which require a treatise to explain and expose the right way. Then I shall
two proposals which are very similar but mutually exclusive, as you will note below, but are intended to provide an alternative to current design standards, design and development of databases.

Start with a common basis for both proposals: Proposal

design and conventions for databases:

  • The names of both entities and attributes (tables and fields) must be written in capital letters. Characters may be used [AZ] [az ][_][ 0-9]: This is done because of various limitations of databases particularly old, so you should avoid using special characters for compatibility, but if you have a database with support for different encodings exist, of which I personally recommend the UTF-8, since it is universal and is governed by the UNICODE standard. I recommend that you use special characters, and these greatly facilitate the reading of each of the sentences, but must take into account each of the limitations of databases and especially changes that generate SQL statements, therefore, wear but considering that this requires minor changes in the generation and special creation of SQL queries.
  • The name of an entity or a field can not start with numbers: Although at present it is possible, you should not even think it does not show any case where required, if any, would love know, but until that happens, you should not do.
  • The name of the entity or field, in the event that is composed of two or more words, they must be separated by an underscore (eg personal_departamento)
  • An entity name can be composed of two parts: a prefix of some characters that indicates the scope of use of the company or its principal membership either a subject or module and a name that represents the identification of the entity, united by an underscore
  • For any case the names of the fields or entities, should ensure that they are not too extensive, leaving aside the expressiveness and
  • clarity
  • names names of entities and fields should be written in the singular and for them to avoid the use of verbs
  • fields that are key primary entity must be denoted with the prefix or suffix ID, and the name of the entity without prefix (if any) joined by an underscore preferably.
  • foreign key fields and primary keys with which they relate should be of the same name, except when an entity has more than one foreign key to the same primary key. In this case will be an appropriate name that represents the relationship.
  • Boolean fields but should be avoided by using lists, if any, should be in a participle in the case of verbs or use any prefix or suffix that identifies them as such, separated by an underscore

But regardless of any theory, standard or rule, the general rule for the development, design and implementation of databases is in a primitive simple enough.

If anyone who sees the design can define the operation, logic and meaning of each of the entities and their relationships can be considered that the work has been completed successfully