The University of Chicago has already just done this.
The only way to fix the patent problem is to shove GOBS OF MONEY down the throats of ever hungry politicians and their banks.
I see this all the time (I have a PhD in the humanities and I am a software engineer) where someone from outside the field does something and claims it is a universal law but really, they just worked on English and cannot (or will not) prove that it works for other languages. Usually, these papers also lack any kind of literature review and ignore many of the problems that this would uncover. I saw one paper by a physicist that tried to use bit fields to model language change; it was just massively reductionist and couldn't explain anything at all for all the mathematical rigour.
I go to my University's language lunch which has lots of this and scare the pants off grad students by saying "this is all very well but does this work for Japanese or Old Irish or any other language?" This usually makes their faces go white because naturally English is the ONLY language that matters and is therefore "universal".
A lot of Historians might well agree with you. But I disagree on this point.
Modern history is a science. Or at least, it is more a science than an art. Historians may have hypotheses, but they must search for sources, categoring [sic] them according to primary and secondary, etc, in order to provide "evidence" for their theories. History is backed up by archaeological evidence, and archaeologists are most definitely scientific in their methods. For falsifiability fetishists, any historical theory can be disproved with the right evidence. While that may be hard to find, everything in history is in principle falsifiable.
The heart of the argument about scientific history is: is a historian specifically unbiased in his/her interpretation of the primary evidence? Is the historian unknowingly biased by the culture in which they live? I would answer this in the affirmative and thus history is not a science. This is a fundamental tenant of Historiography. I am also puzzled by what you mean by "modern history". Do you mean history within the last fifty years or do you mean historical methods since von Ranke?
As technology has improved, it has found its way more and more into historical studies. Things like X-ray scans, etc, used to find erased documents in old parchments. Things like putting the index of soldiers in the hundred years war in a database.
Merely putting data in a database is not History. It may come from historical sources but until someone places an interpretation on the data, it is just data. Even applying mathematics to the data is an interpretation of some kind.
History is a science, or at least, it is scientific in its methods. It's a worthwhile inclusion into an education.
If and only if you ignore the fact that the interpreters of primary evidence have unknown and unstated biases to their interpretations.
The subjects I was speaking of; things like art studies, poetry, philosophy, music, civics, etc, may all be worthwhile subjects, but they don't constitute an education. They constitute a pastime.
I would like to see a history of the Roman Empire without resort to their poetry, philosophy, or art for argumentation or explication. What it seems you misunderstand are the drivers of history are often those very things you dismiss as "pastime". For instance, Christianity has been a massive driver of history so attempting to write about late antique and medieval history without understanding the philosophical and theological arguments of the time (however flawed by the act of interpretation of a historian) would be unedifying.
One last comment. The primary sources are not unbiased themselves. Even archaeological evidence is biased in some manner (ie a burial is often times a statement made by the living about the dead and themselves with some meaning even if we have no idea what the meaning might possibly be). Primary evidence, especially documentary evidence, is often third hand: eye witness sees an event (first hand), eye witness writes down an account of the event (second hand and its own interpretation of history as it is describing something in past time), historian writes about the event (third hand and an interpretation on an interpretation). Even if the historian has more than one account that does not mean the historian has any better understanding of that event than the people who were there. The historian is not a third impartial eye on an event (or set of events). The historian must imagine the event and thus is already at a major philosophical problem that must be addressed before one can continue (I would refer the reader to a recent volume of the journal of History and Theory on the "presence of history").
As long as humans are the actors (with all of their irrationality, culture, and "pastimes") and future humans are the interpreters (with all the same plus the differences in language (something I deliberately missed out because translation of historical sources from one language into another is another huge source of subjective interpretations) and culture), History cannot be a science.
I just could not let this go. I have a question. How do you have a child "learn the history of their own country" without Historians? The last time I checked History was considered an Arts and Humanities subject. People who are by your own statement: "Arts and Humanities [are] students who know how to appreciate everything and know how to do absolutely nothing. People who can master the art of appearing intelligent whilst remaining shockingly ignorant. People whose ideas and tastes and practices are simply imitations of something that was actually original." You will have your hypothetical child taught by these people or is History somehow exempt in your scheme?
Sun, perhaps unfairly, represents a fading Unix market. Red Hat, for its part, represents the rising Linux market.
Given enough time for its open-source strategy to play out, Sun's market capitalization will likely recover and outpace Red Hat's. But for now, a symbolic moment is about to occur. The inauguration of the Linux-based economy?"
Link to Original Source
The nation's first free live public webcast of a federal court hearing — one concerning a lawsuit by the US recording industry against a Boston University graduate student accused of downloading music illegally — has been postponed for a month.
Gertner denied the RIAA's request for a permanent stay but said in a ruling late Tuesday that postponing the hearing until Feb. 24 "will allow the First Circuit an opportunity to fully consider the petition before it.""
Link to Original Source
Link to Original Source
While the main purpose of the book is to provide a reference for the experienced GTK+ developer, the layout of the chapters emphasizes teaching the beginner the basic structures of a GTK+ program all the way to advanced topics such as developing custom widgets and the Glade GUI builder application. Many of the most important details, such as various enumerations, are placed appropriately in the appendices while those that are used are clearly detailed in the text.
As Krause focuses on the foundation of GTK+ development, all the examples are in C and the reader should be prepared with a good knowledge of C. While there are many different languages which have bindings for GTK+, which allow programmers to use their programming language of choice, the advantage of learning the C foundations of GTK+ is that the reader gets a clear understanding of how the library works "under the hood". The reader will appreciate how their chosen bindings interact with the base library.
Each chapter begins with a list of what a reader will learn and ends with a summary of the major points of the chapter followed by an exercise. These exercises are designed to be broad and leave much for the reader to do and learn with in the structure given by the exercise. If the reader becomes stuck the website has the appropriate sources to help the reader understand the structure being used within the program to achieve its ends.
Chapter 1 gives the history of the GTK+ project, X11, covers the installation of the details of the libraries involved in developing GTK+ applications. The exercise at the end of Chapter 1 has the reader verify the installation of the GTK+ libraries.
Chapter 2 is where the rubber hits the road as far as programming with GTK+ is concerned. The "Hello World" program gives the general structure of GTK+ development, which is maintained through out the following chapters. The widget hierarchy is discussed as well as how to cast objects properly ensuring correct pointer type to each particular function. All the signals and event handlers are discussed at a proper level of detail for a beginning chapter. If this were the only chapter, it would provide any programmer with enough detail to begin exploring the API and begin their own application.
Chapter 3 and 4 cover container widgets, which control layout and decorations, which allow different effects on widgets, and basic widgets (e.g. GtkToggleButton, GtkCheckButton, etc.). These are the basis for any good windowing toolkit and they are demonstrated ablely and with confidence by an author who is clearly comfortable with the toolkit and has no trouble articulating this to his reader.
Chapter 5 covers the different stock dialogs which come with GTK+, the About dialog, Information dialogs, and the FileChooser dialog, etc. While these are useful, building your own dialog boxes are left until later chapters but this chapter does give the reader a feel for how to use dialogs and where to place them in your program source for maximum readability.
Chapter 6 is an odd chapter as it covers GLib and is not related directly to GTK+ but it is necessary as some GTK+ functions return structures from this library. While it does give the reader a break from learning directly about GTK+, it seems oddly placed however as it needed to go somewhere and Chapter 6 is as good as any other chapter. This chapter is the longest chapter in the book and the author gives the reader a well deserved pat on the back at the end.
Chapter 7 and 8 are devoted to the most complicated but useful widgets, TextView and TreeView. The TextView widget allows many different operations for displaying text and the reader is introduced to many of the functions that would allow one to write a word processor. This chapter is helped heavily by the fact that the Krause is the developer of an application that uses this widget heavily. The use of the Pango library and the facilities for fonts are also covered in this chapter. In the next chapter, the reader is taken for a tour of the TreeView widget which mostly consists of creating different renderers for the different cells. The reader is given useful advice about which to use where and where to avoid using renderers which are called too often.
Chapter 9 describes how to build menus, toolbars, and popup menus both manually and with the XML based mark-up language which comes with GTK+. The reader is also introduced to the method for creating their own stock icons for the tool bars and menu items. This chapter basically completes the core development needs of an application programmer and if the book stopped here, it would be well worth purchasing. The reader should now be acquainted well enough with GTK+ to explore the API for needed functions and structures themselves. The XML demonstrated is a help as much of the code for this section is a tad boring and repetitive and the XML allows the reader to quickly create the required objects for the system.
Chapter 10 is another break from direct GTK+ development and the author has a few points about user interface design before showing the reader the Glade UI designer and libglade, which is necessary to use the interface builder. Much of a GTK+ application can be created from Glade but, as Krause rightly cautions the reader, there is still much development that needs to occur for the application to have the correct behavior. The XML created by Glade is similar to that used in the previous chapter but it covers much of what a developer would need in an application. While some may have wished that Glade was introduced earlier in the course of the book, Glade is an advanced topic and it is beneficial for the reader to understand how to create applications without Glade so that one could appreciate the design decisions when developing with GTK+.
Chapter 11 shows the reader how to create custom widgets within the toolkit from scratch which exposes in detail the inner workings of GTK+. Here Krause demonstrates using an IP input widget and a marquee widget. This chapter is quite long and involved and may take more than one read but it is well worth the exercise to understand more about the internals of the widgets that were introduced in earlier chapters.
Chapter 12 is a miscellaneous chapter with some interesting widgets that did not fit into the structure of the previous chapters including the helpful GtkPrintOperation. Chapter 13 gives you five applications built with the facilities of the previous chapters and the code for these can be obtained from the book's web site. The appendices follow and contain much information that is helpful when creating applications with GTK+.
For the beginner, this book is an invaluable resource for learning about GTK+. The content is substantive and concise while maintaining consistency throughout. The consistency, especially in the code sections, reinforces the information presented and code structure, which helps the beginner keep good coding style when writing for GTK+. The book remains tightly focused on presenting this sometimes daunting amount of information, which is one of the other great qualities of the book. For the expert, the table of contents, the appendices, and the index are the most important aspects of the book. These parts of the book are amply treated so that it is easy to use the book as a quick memory refresh. Overall, this book is a solid and dependable guide to a large windowing toolkit and should sit comfortably on any GUI application developer's desk."
Link to Original Source