Softpanorama Java Bulletin, 2005

Highlights of the year

• O'Reilly Radar The Rise of Open Source Java Contains the updated trend graph showing programming language market share as reflected by weekly book sales reported by Neilsen Bookscan from January 2003 to mid-June 2005...

• Slashdot/James Gosling on Java Javascript has been called Lisp in C's clothing. Javascript (via Rhino) will be included in Java 6. I also read that Java 6 will allow access to the parse trees created by the javac compiler (same link as Java 6 above).

[Dec 15, 2005] James Gosling on the Java Road 

He definitely does not understand the difference  between programming in the small and programming in the large. Just like Stallman he completely misunderstands this issue. Java still might became a viable "programming in the small language" but Java stands no change to survive as "programming in the large" language.  That's why .Net  gave Java a run for its money and I think that IBM will soon feel the pain. Microsoft is a serious player and does not like to take prisoners. That's spell huge trouble for IBM's Websphere business.

Over the years I've used and created a wide variety of scripting languages, and in general, I'm a big fan of them. When the project that Java came out of first started, I was originally planning to do a scripting language. But a number of forces pushed me away from that.

The biggest was concerns about performance and the inevitability of scale. I can't remember how often I've had experiences where someone has proudly shown me some system they've put together using the scripting-language-du-jour: things like an Adobe Illustrator clone written entirely in PostScript; a satellite groundstation diagnostic system written as TECO macros; a BASIC compiler written as Emacs macros; fourier transform algorithms in PostScript... This list is endless. They always ended with "this is so cool, but I'd like it to be as fast as {C,Assembler,whatever}". People get into scripting to quickly build small quick things, but they often grow far beyond where the initial concept started.

Another was about testing, reliability and maintainability. One of the common properties of scripting languages is brevity. This tends to lead to omitting declarations, weak typing and ignoring errors. Generally a great thing if you're quickly putting something together; not so great if you want checks and balances that crosscheck correctness.

Another is generality. Many scripting languages get a good part of their coolness from being specialized - by having key functionality wired into their hearts. A good example is perl, with it's great regular expressions and hash tables. But this drags in a number of issues, chief among them being: what if you want to do something outside the language's area of specialization? Many modern apps need to do exactly that, so one of two things happen: languages get used for wildly inappropriate things (fourier transforms in PostScript), or a collection of languages get used together (which can make it very hard for any one person to understand them, and interconnections can be a nightmare).

The list of interesting questions is really long, this blog entry could easily be a book (that I'll never have time to write). This hardly scratches the surface. The number of potential PhD thesis topics is huge.

[Aug 13,  2005] Diego Pettenò - [Rant] The Java t...crap

An open letter to Eclipse membership from Sun

Re:Java is crap (Score:0)

By Anonymous Reader on 2004.02.02 15:37 (#85310)

Not the original poster but...

I would love to see you write some "small" enterprise application in Python, Perl or PHP.
All language serve a particular purpose and enterprise applications is not one the purposes of the languages mentioned as an alternative.

That is what's happening allover the places. Sure, Java got some more credibility, and maturity to it. I'll give sun that. But clanking on PHP/python is a no-no. :D

[Jul 21, 2005]  Alternatives to Java

When all you have is a hammer, most problems look a lot like nails. Since you’re reading this book, I’m willing to bet that Java is your hammer of choice, and indeed Java is a very powerful hammer. However, sometimes you really could use a screwdriver; and this may be one of those times. I must admit that the solution for imposing hierarchy developed in the last section feels more than a little like pounding a screw with a hammer. Maybe it would be better to use the hammer to set the screw, but then use a screwdriver to drive it in. In this section I want to explore a few possible screwdrivers including XSLT and XQuery. Rather than using such complex Java code, I’ll use Java to get the data into the simple XML format produced by Example 4.2 that closely matches the flat input data. Then I’ll use XSLT to transform this simple intermediate XML format into the less-flat final XML format. To refresh your memory, the flat XML data is organized like this:

[Jul 21, 2005] Evaluating Java for Game Development

Pretty interesting report.

Published March 4th, 2002
by Jacob Marner, M.Sc.
The Department of Computer Science
The University of Copenhagen, Denmark.

---

The purpose of this project was to examine whether the use of Java for games is advantageous compared to the current languages of choice, C and C++. This is not an easy question to answer, and as you will see in the report, the answer will depend on several project specific issues.

The main target group of the report is professional game programmers with little or no knowledge of Java, who wonder whether Java would be beneficial in future projects. The report generally assumes that the reader is skeptical about Java.

The focus of the report is on games intended for retail; not on Java applets.

---

The report is 87 pages long not including appendixes. Including appendixes it is 314 pages long. If you do not have the time to read it all, I recommend that you just read chapter 9 and, if you have the time, also chapter 8. Be sure to read the errata and clarifications webpage too in order to avoid some common misunderstandings and to get updates on later developments that not make it into the report.

---

The report was turned in as a graduate project (I was a graduate student at the time) and was graded A+ at the university (In the Danish grade system the grade was 13, which is the maximum possible grade). It was credited with 12.5 ECTS.

AT&T Labs Research - Yoix

The Yoix scripting language is a general-purpose programming language that uses syntax and functions familiar to users of C and Java. It is not an object oriented language, but makes use of over 150 object types that provide access to most of the standard Java classes. Because the Yoix interpreter is built entirely using pure Java^TM technology, it means that Yoix applications are cross-platform, GUI-capable and both network and thread friendly, yet Yoix developers find themselves insulated from the more cumbersome and tricky parts of coding the same functionality directly in Java. It does not use reflection to access Java functionality and thus adds value by not only simplifying access to that functionality, but also improving application reliability by coding through Java gotchas and complicated Java features one-time, behind-the-scenes. The Yoix language includes pointers, addressing, declarations, and global and local variables. In addition to supporting native user functions, users can add their own builtin functions written in Java. Yoix technology has been employed to build critical AT&T systems that run 24/7 and are accessed by hundreds of users in geographically dispersed locations.

Pointers?

When people first hear that the Yoix language includes pointers, their first reaction is usually a knee-jerk revulsion. "Pointers?" they say, "Aren't those a recipe for memory corruption, unexpected results and memory management issues?" As implemented in the Yoix interpreter, the answer is, quite simply, no. Pointers here are a syntactic tool that acts as both a shorthand and a convenience in a variety of situations. At the end of the day, their implementation relies on Java, thus the issues of memory management and memory corruption are moot. Moreover, unexpectedly pointing to inappropriate data will generate a (catchable) Yoix exception. In short, using pointers in Yoix is no more dangerous than using arrays in Java.

An interpreted language written in Java?

Though the fact that the Yoix interpreter runs under the Java Virtual Machine means that we do not recommend Yoix technology for implementing missile guidance systems or other real-time applications, Yoix does perform quite well and there are a surprisingly large number of applications where a Yoix implementation is the right way to go. In particular, client/server applications where the computationally intensive parts of the application can reside on the server, written using whatever tools are most suitable, while the client-side is primarily a graphical user interface (GUI) are perfect. The World Wide Web is a familiar example of just this model. For these sorts of applications, writing the client-side using Yoix technology means that only the generic Yoix jar file has to be distributed to end-users, the application-specific Yoix scripts can be downloaded at run-time as needed, much like a browser downloads HTML. With that model, application bug-fixes and upgrades are trivial, yet end-users experience the full functionality of a Java application.

Programming Tools Java Scripting Languages Linux Journal

I recently returned from JavaOne 2005 in San Francisco. The show was impressive for a number of reasons. The attendance seemed to be about 30% larger than last year's. The same could be said for the number of tutorials, sessions and BOFs. For example, there were enough BOFs to run until 11:00pm at night. Many of the sessions were filled to capacity, with over 600 attendees each technical presentation.

Given my strong background in C++, I am used to a more amorphous attitude toward languages. Therefore, I was surprised to see that there still is a vibrancy to Java that I do not see with C++.

Among the many interesting things that I saw, two stand out: Eclipse and the scripting language called Groovy. I already have written about Eclipse, so here I simply note that Eclipse now seems to dominate the Java IDE world. Groovy, on the other hand, is new. It prompted me to look at Python-like scripting languages that run in a Java environment.

In this article, I discuss Jython and Groovy, two scripting languages that use the Java runtime environment. By the way, JavaScript has nothing to do with the Java language, so it is not considered here.

Jython

Jython is an interpret

uilt-in entities, Jython produces Java compatible structures that it passes back and forth to the JVM. The code below uses the Jython interactive shell, in which Jython takes the Python built-in list structure and converts it to a Java list structure that is then passed to the Java println function that then passes the result to the JVM.

>>> print ['a','list','of','strings']
['a', 'list', 'of', 'strings']
>>>

Here is a simple program that uses the Java Swing library to produce a trivial GUI application:

"""\
A simple demonstration of creating a swing tree widget from a
Python dictionary.
"""
import java
import javax
from pawt import swing
from pawt import awt
sampleData = {
  'PyObject': {
        'PyInteger':None,
        'PyFloat':None,
        'PyComplex':None,
        'PySequence': {
          'PyArray':None,
          'PyList':None,
          'PyTuple':None,
          'PyString':None,
        },
        'PyClass': {
          'PyJavaClass':None,
        },
  },
  'sys':None,
  'Py':None,
  'PyException':None,
  '__builtin__':None,
  'ThreadState':None,
}
Node = swing.tree.DefaultMutableTreeNode
def addNode(tree, key, value):
  node = Node(key)
  tree.add(node)
  if value is not None:
    addLeaves(node, value.items())
def addLeaves(node, items):
  items.sort()
  for key, value in items:
    addNode(node, key, value)
def makeTree(name, data):
  tree = Node("Sample Tree")
  addLeaves(tree, data.items())
  return swing.JTree(tree)
def exit(e): 
  java.lang.System.exit(0)
if __name__ == '__main__':
  tree = makeTree('Some JPython Classes', sampleData)
  button = swing.JButton('Close Me!', actionPerformed=exit)
  f = swing.JFrame("GridBag Layout Example");
  p = swing.JFrame.getContentPane(f)
  gb = awt.GridBagLayout()
  p.setLayout(gb)
  
  c = awt.GridBagConstraints();
  c.weightx = 1.0;
  c.fill = awt.GridBagConstraints.BOTH;
  
  gb.setConstraints(tree, c);
  c.gridx = 0;
  c.gridy = awt.GridBagConstraints.RELATIVE;
  gb.setConstraints(button, c);
  p.add(tree)
  p.add(button)
  f.pack();
  f.setSize(f.getPreferredSize());
  f.show();

Jython has two main advantages. First, the language is Python and has all of its strengths, including clean and consistent syntax, introspection, dynamic creation of classes, properties and attributes. Second, it runs at the speed of the JVM. On the other hand, Jython also has two chief weakness. First is its need to convert constantly between Python and Java structures. Second, Jython has not received much work in recent years. That is about to change, however; the current maintainer, Brian Zimmer, recently received three grants to continue work on Jython.

The bottom line is if you know Python, then you know Jython. The big gain is ready access to libraries such as Swing, awt and so on.

er for the Python language. It is written in Java to run under the Java VM. To handle Python b

Groovy

Groovy is a new language based on features from Ruby, Python and Haskell. However, its runtime environment is any JVM. The language syntax attempts to be Java-like, while making the form of the language much simpler. Groovy is a statically typed language, so it requires a compile step before producing Java byte code. Groovy does not currently have an interpreter, although it does have a shell.

Groovy documentation offers an impressive list of features:

• Closure support
• Native syntax for Lists and Maps
• Groovy Markup
• Groovy Path expression language
• Groovlets for implementing Servlets easily in simple Groovy scripts
• Groovy SQL for making SQL more Groovy
• Groovy Beans for simpler syntax for working with beans
• Groovy Template Engines which are pluggable, simple to use, integrate GPath and compile to bytecode
• Ant scripting
• Regex syntax for neater scripting with regular expressions
• Operator Overloading to simplify working with datatypes Collections and Maps
• Polymorphic iteration and autoboxing
• Compiles straight to Java bytecode
• Works cleanly with all existing Java objects and libraries

An interesting feature of Groovy is found its definition and use of closure:

A closure in Groovy is an anonymous chunk of code surrounded by braces that takes zero, one or more arguments, returns a value, and can reference and use variables declared in its surrounding lexical scope (i.e., the scope at its definition point). A closure is like an anonymous inner class in Java. It is often used in the same way. However, Groovy closures are more powerful and often more convenient to specify and use.

Groovy's uses Java's standard types for things such as dictionaries and lists. This means no translation is needed between Groovy code and the JVM. This may improve execution time, depending on the application.

Closures and Anonymous Classes

Groovy's documentation provides an example that illustrates the benefits of using closures in place of anonymous classes. Using an anonymous class, we can write:

Button b = new Button ("Push Me");
  b.onClick (new Action() {
    public void execute (Object target)
    {
      buttonClicked();
    }
  });
</programlisting>
<para>
Using a closure, this becomes:
</para>
<programlisting>
Button b = new Button ("Push Me");
  b.onClick { buttonClicked() }

Another nice feature of Groovy is its "each operator, which is used to iterate over a collection:

SomeCollection stuff = new SomeCollection();
  stuff.each() someClosure
// for example:
def myList = [1,2,4,5,6]
myList.each { println it }  // where 'it' is current collection item
// outputs:
1
2
3
4
5
6

Groovy also has built-in structured "builders" for languages such as XML, HTML and more. Again, a simple example illustrates how natural it is to build structured text:

xml = new groovy.xml.MarkupBuilder()
def myList = ['acct1':['id':123111, 'type':'savings', 'balance':1234.56],
              'acct2':['id':221212, 'type':'checking', 'balance':2010.02]]
doc = xml.accounts() {
  for (entry in myList)
    acct(id:entry.key) {
      for (thing in entry.value)
        item(name:thing.key, type=thing.value)
    }
}

This small code fragment outputs:

<accounts>
  <acct id='acct2'>
    <item name='type'>checking</item>
    <item name='id'>221212</item>
    <item name='balance'>2010.02</item>
  </acct>
  <acct id='acct1'>
    <item name='type'>savings</item>
    <item name='id'>123111</item>
    <item name='balance'>1234.56</item>
  </acct>

Contrasting Jython and Groovy

Bindings

In the following example, the use of variable c is caught at compile time in a statically defined language. Only when a is greater than b is the use of the undefined variable, c, detected in an interpreted language.

a = 1
b = 2
if a > b:
  print c
print a,b

Another major difference between a compiled language and an interpreted one is when things are bound to their references. In Groovy, the following code prints "Bound to local variable":

def varA = "Bound to global variable"
def closure = { varA }
public class C {
  def varA = "Bound to local variable"
  def closure = { varA }  // bound to local varA at definition time
  public def f = closure  // f bound to local closure
};
def c = new C();          // create instance of C using new
println c.f()             // invoke f in C

in Jython, the equivalent-looking code prints "Bound to global variable":

varA = "Bound to global variable"
closure = lambda: varA
class C:
  varA = "Bound to local variable"
  closure = lambda self: varA
  f = closure
c = C()
print c.f()

For those wanting more flexibility, the Jython/Python bindings are handier. For those wanting more stability, the Groovy implementation may be more desirable.

Currying

Currying function arguments is another difference. Groovy has a special "curry" mechanism to bind arguments to a function. In the following example, "foo bar" is printed:

def c = { arg1, arg2-> println "${arg1} ${arg2}" }
def d = c.curry("foo")
d("bar")

Jython inherits Python's natural ability to curry arguments using a number of techniques. One is:

def c(arg1, arg2): print arg1,arg2
def d(arg2): c("foo",arg2)
d("bar")

Maturity

Jython has been around a long time and is based on a mature language, Python. However, its development has stalled in recent years. Groovy is a relatively new language and thus still is developing. For example, its error diagnostics leave a lot to be desired. Also, at the moment, Groovy's following is much smaller than Jython's or Python's. However, both languages are picking up development activity, so you have a chance to influence both languages if you want to become involved.

[Jun 30, 2005] Gosling A closer look at Java - page 2 Tech News on ZDNet

[Jun 30, 2005] Slashdot/James Gosling on Java

Page 2 and scripting languages (Score:5, Interesting)
by MarkEst1973 (769601) on Thursday June 30, @09:59PM (#12956728) The entire second page of the article talks about scripting languages, specifically Javascript (in browsers) and Groovy.

1. Kudos to the Groovy [codehaus.org] authors. They've even garnered James Gosling's attention. If you write Java code and consider yourself even a little bit of a forward thinker, look up Groovy. It's a very important JSR (JSR-241 specifically).

2. He talks about Javascript solely from the point of view of the browser. Yes, I agree that Javascript is predominently implemented in a browser, but it's reach can be felt everywhere. Javascript == ActionScript (Flash scripting language). Javascript == CFScript (ColdFusion scripting language). Javascript object notation == Python object notation.

But what about Javascript and Rhino's [mozilla.org] inclusion in Java 6 [sun.com]? I've been using Rhino as a server side language for a while now because Struts is way too verbose for my taste. I just want a thin glue layer between the web interface and my java components. I'm sick and tired of endless xml configuration (that means you, too, EJB!). A Rhino script on the server (with embedded Request, Response, Application, and Session objects) is the perfect glue that does not need xml configuration. (See also Groovy's Groovlets for a thin glue layer).

3. Javascript has been called Lisp in C's clothing. Javascript (via Rhino) will be included in Java 6. I also read that Java 6 will allow access to the parse trees created by the javac compiler (same link as Java 6 above).

Java is now Lisp? Paul Graham writes about 9 features [paulgraham.com] that made Lisp unique when it debuted in the 50s. Access to the parse trees is one of the most advanced features of Lisp. He argues that when a language has all 9 features (and Java today is at about #5), you've not created a new language but a dialect of Lisp.

I am a Very Big Fan of dynamic languages that can flex like a pretzel to fit my problem domain. Is Java evolving to be that pretzel?

Scripting language talk... (Score:3, Insightful) by MrDomino (799876) <mrdomino.gmail@com> on Thursday June 30, @10:19PM (#12956857)

From TFA: When people talk about scripting languages, they often talk about things that are more toward having a developer be able to slap something together rally quickly and get a demo out the door in minutes. How fast the thing runs or how well the thing scales or how large a system you can build tend to be secondary considerations. ... This is nit-picking, I know, but I was under the impression that scripting languages were actually defined by the presence of an actively-running interpreter during execution, making it possible to, e.g., construct and execute statements at runtime with things like PHP's exec() or Lua [lua.org]'s do(file|string) functions (see: http://www.lua.org/pil/8.html [lua.org] for discussion on dofile and Lua's status as a scripting language). I wasn't aware that capability for rapid prototyping or language speed had anything to do with it. Taking that into consideration, then, would Java with JIT [wikipedia.org] qualify as an interpreted or compiled language? I'm not sure, myself---any thoughts? That aside, a solid interview. Java looks to be pretty interesting; though in its current form it does bug the hell out of me (System.out.println()? Yeah, yeah, OO, but come on, three nested levels of scope just to get to a command line?), its progress has been impressive, and it's an innovative idea.

Java - unfulfilled promisses (Score:2) by guacamole (24270) on Thursday June 30, @10:50PM (#12957047)

I think the biggest selling point of Java was the cross-platform compatibility. However, 10 years later, I think that it is clear that this promise was largely a fraud. Java was a perhaps a good new platform for writing enterprise applications and applications for certain consumer niches for those developers who didn't want to deal with the unsafe languages like C or C++ or those who were fooled by Sun into believing that Java is the best thing since whatever, but cross-platform compatibility for large applications still remains problematic. For example, most vendors of fairly complex java applications I have seen, not only require you to use a certain version of OS and a web browser (if that's an applet) but also they demand a certain version of the java virtual machine is used and with certain patches on some operating systems. And if you don't meet their requirements, you often run into problems. I bet a python or a perl script would have fared much better in many of those settings as far as portability is concerned.

 [Jun 18, 2005] O'Reilly Radar The Rise of Open Source Java

[Apr 20, 2005] JRegexer 0.3  This version removes external browsing, adds a simple internal browser for viewing JavaDoc, adds support for find, find/start, split, and split/limit, adds automatic recompilation and parsing, improves the formatting of results, and fixes a few bugs.

JRegexer is a small and simple tool to develop and test regexes that are parsed with java.util.regex.*.

Incipient(thoughts) Throw some Java salt over your shoulder

I'm fairly sure you could accurately gauge the maturity of a programming team by the amount of superstition in the source code they produce. Code superstitions are a milder form of cargo cult software development, in which you find people writing code constructs that have no conceivable value with respect to the functions that the code is meant to fulfill.

A recent conversation reminded me of an example I find particularly disturbing. Sample code for dealing with JDBC is particularly prone to being littered with this particular error, as shown below. (I suspect that is not coincidental; I'll be coming back to that.) I have elided most braces out for clarity and terseness - imagine that this is a cross between Java and Python:

import java.sql.*; 

public class JdbcSample {
  public static void main(String[] args) {
    Connection conn = null;
    try
      conn = DriverManager.getConnection("jdbc:someUrl");
      // ...more JDBC stuff...
    catch (SQLException ex)
      // Too often that is silently ignored, but that's another blog entry
    finally
      if (conn != null)
        try
          conn.close();
        catch (SQLException sqlEx)
      conn = null; 
  }

The "superstition" part is that setting the connection to null can have absolutely no useful effect; being a local variable, "conn" will become eligible for garbage collection as soon as it goes out of scope anyway, which the most rudimentary analysis of flow control reveals it will immediately after being set to null.

I am always particularly interested in finding out what goes on in the minds of programmers who write this kind of thing, because that will sometimes reveal the roots of the superstition. Most of the time, though, if you raise question in a design review the programmer will say something like "I copied and pasted it from sample code". This is how the superstitions spread - and it's also a red flag with respect to the team's practice maturity - but rarely an occasion to gain insight into why the superstition took hold, which is what you'll need to know in "remedial" training.

Now, the "null" concept, obvious as it seems, is a likely place for superstitions to accrete around. If you look closely, "null" is nothing but obvious. Comparing Java and Smalltalk, for instance, we find that they differ radically with respect to calling instance methods on null, or "nil" as it's called in Smalltalk; "nil" does have some instance methods you can call. Also, what is the type of the "null" value in Java ? It is a special type called "the null type", which looks like a sensible answer but incidentally breaks the consistency of the type system; the only types which are assignable to variables are the type of the variable or subtypes of that type, so "null type" should be a subclass of every Java class. (It actually works that way in Eiffel, as Nat Pryce reminds me - see comments.)

See also here for another example of a null-related Java superstition, also surprisingly common, as you can verify by Googling for "equals null".

In the case of JDBC, I would bet that idioms of resource allocation and deallocation inherited from non-garbage collected languages, like C, were the main force in establishing the superstition. Even people new to Java get used to not calling "dispose" or "delete" to deallocate objects, but unfortunately the design of the JDBC "bridges" between the object and relational worlds suffer from a throwback to idioms of explicit resource allocation/deallocation.

Owing to what many see as a major design flaw in Java, "going out of scope" cannot be relied on as an indicator that a resource is no longer in use, either, so whenever they deal with JDBC Java programmers are suddenly thrown back into a different world, one where deallocation is something to think about, like not forgetting your keys at home. And so, in precisely the same way as I occasionally found myself patting my pockets to check for home keys when I left the office, our fingers reflexively type in the closest equivalent we find in Java to an explicit deallocation - setting to null.

You may object that the setting-to-null superstition is totally harmless. So is throwing salt over your shoulder. While this may be true of one particular superstition, I would be particularly concerned about a team which had many such habits, just like you wouldn't want to trust much of importance your batty old aunt who avoids stepping on cracks, stays home on Fridays, crosses herself on seeing a black cat, but always sends you candy for Christmas.

Posted by Morendil at November 15, 2004 04:57 PM

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019