Stoopid Idea of the Day: Five lines or less

Oh hey, an interesting StackOverflow question:

http://stackoverflow.com/questions/811074/what-is-the-coolest-thing-you-can-do-in-10-lines-of-simple-code-help-me-inspir

Of course it was closed as unconstructive.

How about five lines? One hand, one statement per finger, if you need that.

Pointer finger: demonstrably state the input instruction/line

Middle / Ring / Pinky: demonstrably process the input

Thumb: demonstrably output or return (ok, if you really need to do some processing here in the return...)

Line count doesn't include basic stuff like function bodies, class overhead, imports, etc. 

Also, state language, environment/os/libraries needed.

If your "line" is longer than, oh, 120 characters, then is that really a line? As in, if you are a master of obfuscated C/C++, please, just don't...

APL is also cheating. 

Heavy UNIX commands... well, I guess everything is relative...

People: readable five lines of code that perform a useful, adaptable, extendable purpose.

Some good tagging and relations plus moderation... 

Yet another build system? Please?

Problem: Most gradle/ant builds turn into groovy/XML soup

Problem: Gradle/Ant projects can lack a good idea of "where to start" to build something. What properties do I need to define? What order of tasks? What do the tasks depend on (db, etc)?

Problem: Maven is a PITA and inflexible, and the advocates are tyrannical

Problem: Maven still ends up with a massive huge xml file

Problem: Maven won't do simple, literal directory-of-jars

Problem: Maven's internet connection dependence

Problem: If maven dep-resolve fails you (IBM Websphere, another reason to hate you), you're basically screwed.

------------------------

What are the good parts that have been invented:

- (Ant) a general set of plugins for templating/replacement, files, building code, etc etc.

- (Ant) decent IDE support

- (Maven) maven repository: the failed dependency resolution is a rare case. Generally, this thing is a very good thing for code sharing and library use/reuse. Gotta leverage this massive body of work and mindshare.

- (Maven) standard project structure: although src/main/java isn't my favorite thing (three levels down? really?), the overall maven project structure provides acceptable structure that people are used to now.

- (Maven) standard project structure for WARs: again, I am not too excited about the file structure, but it'll do.

- (Maven) standard jar naming <artifact>-<version>.jar, a great thing indeed

- (Maven) binary / javadoc / source jars

- (Gradle) groovy scripting for those things you need scripting

-----------------------

What I want from a build system

-  leverage the structuring standards of Maven that have made unfamiliar projects more straightforward to interpret

- leverage Maven repos and dependency maps, but add flexibility fallbacks for literal jars, and only do dependency resolution when new projects are setup or new libraries/dependencies added (one-off or one-time tasks)

- this is a new feature for java builds: a single file download that specifies where to download the rest of the project (sourcecode, etc). The build system will connect to sftp/ftp/git/subversion/whatever to get the code, then do dep resolve. Kind of like .rpms for linux. Great way to do starting points for projects, especially ones without a fancy site or github...

- use some of the nice features that make Ruby on Rails so good: convention over configuration, and folder structure as configuration. Maven failed at this since you end up with a huge POM xml. 

  - Why not have a naming convention for mulitple source folders: as long as they match /src-* and are at the project root, then they are an additional source folder. 

  - /info dir has the project info. 

  - /lib for various libraries. In the /lib, you can have .jar files for inline/literal inclusion, or an empty file named <artifact>;<version> that triggers dependency resolution. Nice instant  visual indication of the libraries used to build a project. Subdirs for main for main build, test for test build and execute, etc.

  - /tasks is a dir with more subdirs <taskname>, and each of those has their own gradle/ant script that can be invoked

Need to add a quick jar? drop it in the /lib/main dir. Need to add a quick set of dependencies from another project that you know works? Copy-paste the dependency files into the lib dir. Source tree getting a bit thick in the /src/main/java folder? spin off some more src-* source directories. Maybe even tasks can become drag-and-drop or copy/paste with sufficient automation/decoupling. 

Web resources, ears, subprojects, project relationships, etc: all to be determined. 

Another key aspect should be IDE support and multiple IDE usage. perhaps a separate directory tree for ide-specific settings. Ant/Gradle/Maven xmls can be autogenerated for IDE import/usage if need be. 

Project structure:

/	root of project
/lib	libraries and dependencies
/lib/main	libs and deps for main compile
/lib/test	libs and deps for unit test exec
/src	maven-style primary source dir, with /main/java, /tast/java, /main/resource, etc
/src-	more maven-style source dirs, such as a service impl, etc
/task	nonstandard task scripts

Frameworkitis and False Enterprisey Security: WS-Security and signing.

http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx

Who wears a motorcycle helmet indoors? Just because it's a simple analogy doesn't mean it's right.

This is still rampant frameworkitis. HTTPS isn't good enough! What happens if something is done after the message reaches it's point?

Oh, you mean the fucking ENDpoint?

99% of SOAP bloat systems (aka, licensed application servers configured and installed by consultants) IMMEDIATELY deserialize a SOAP message to a datastructure, and from there that data structure will be mangled by database call or MQ message or whatever.

Notice the uselessness of message signing. It's a false security blanket sold to stupid fucking executives. The data will be plaintext in a host of different settings post-parse: SQL requests, followup messages. That requires either good internal data practices or specifically tailored security architecture.

READ: less than 1% of cases, and outside the concerns of SOAP, which is a messaging protocol, not a transport protocol.

It's frameworkitis and enterprisy. Let's add a bunch of stuff that isn't the concern, bloat, bloat, bloat, million dollar license, buy a ferrari.

Fucking software companies. 

A little Spring XML to JSON conversion experiment...

What might some random Spring config (in this case a Spring-batch example) look like if JSON were the configuration/injection message format? What is good, what is bad?

 <bean id="taskletJob" parent="simpleJob">  
   <property name="steps">  
     <list>  
       <bean id="deleteFilesInDir" parent="taskletStep">  
         <property name="tasklet">  
           <bean  
       class="org.springframework.batch.sample.tasklet.FileDeletingTasklet">  
             <property name="directoryResource"  
               ref="directory" />  
           </bean>  
         </property>  
       </bean>  
       <bean id="executeSystemCommand" parent="taskletStep">  
         <property name="tasklet">  
           <bean  
       class="org.springframework.batch.sample.common.SystemCommandTasklet">  
             <property name="command" value="echo hello" />  
             <!-- 5 second timeout for the command to complete -->  
             <property name="timeout" value="5000" />  
           </bean>  
         </property>  
       </bean>  
     </list>  
   </property>  
 </bean>  
 <bean id="directory"  
   class="org.springframework.core.io.FileSystemResource">  
   <constructor-arg value="target/test-outputs/test-dir" />  
 </bean>  

My swing at JSON, using JSON-ish features and advantages (lists, maps/objects, etc)

 {  
   "taskletjob":  
     {"#t":"BEAN", "id":"taskletJob", "parent": "simpleJob",  
     "properties": {   
       "steps": [  
         {"#t": "BEAN",  
          "id":"deleteFilesInDir",   
          "parent":"taskletStep",  
          "properties":  
           {"tasklet":  
             {"#t":"BEAN", "class":"org.springframework.batch.sample.tasklet.FileDeletingTasklet",  
              "properties": {"directoryResource" : {"#ref":"directory"}}  
             }  
           }  
         },  
         {"#t": "BEAN",  
          "id":"executeSystemCommand",   
          "parent":"taskletStep",  
          "properties":  
           {"tasklet":  
             {"#t":"BEAN", "class":"org.springframework.batch.sample.common.SystemCommandTasklet",  
              "properties": { "command": "echo hello", "timeout": 5000}  
             }  
           }  
         }  
        ]  
       }  
     },  
   "directory": {  
     "#t":"BEAN", "id":"directory",   
     "class":"org.springframework.core.io.FileSystemResource",   
     "constructor-args": ["target/test-outputs/test-dir"]  
   }    
 }  

So what I found out:

Size in LOC was mostly identical. No real big savings there.
Spring utilizes namespaces implicitly or explicitly... No real JSON mechanism, so I invented the "#t" which is supposed to indicate the object type if it is typed, to give guidance to some parser/bean construction code as to required fields, etc.

In other places, like properties, the JSON object is used more as a map, since it is more intuitive that way. The JSON format here seems much more natural, and seem to save lots of keystrokes. I mean would you rather type:


<property name="command" value="echo hello" />
<property name="timeout" value="5000" />

or

"properties": { "command": "echo hello", "timeout": 5000}

Clear win for the JSON there.

However, JSON has some weird corner cases in formatting, such as arrays of objects. How do you render that without wasting extra tabs or lines? Granted, the <list> construct in spring xml wastes a tab and a line...

And all the double-quotes in JSON. Annoying. Not as annoying as xml ending tags. And why are commas even needed?

Other JSON problems: Getting lost in curly-brace land. WHile annoying verbose, at least closing tags in XML let you see what's being ended/closed. But considering most modern editors have curly brace features for C and Java code, this isn't a huge deal.

But if I had my druthers with a variation on JSON, where you don't need double-quotes on the object keys, values are optional, and drop the commas, why can't JSON be this?

 {  
   taskletjob:  
     {#BEAN id:"taskletJob"   
     parent: "simpleJob"  
     properties: {   
       steps: [  
         {#BEAN" id:"deleteFilesInDir"  
          parent:"taskletStep"  
          properties  
           {tasklet:  
             {#BEAN class:"org.springframework.batch.sample.tasklet.FileDeletingTasklet"  
              properties: {"directoryResource" : {"#ref":"directory"}}  
             }  
           }  
         }  
         {#BEAN id:"executeSystemCommand"  
          parent:"taskletStep"  
          properties:  
           {tasklet:  
             {#BEAN "class":"org.springframework.batch.sample.common.SystemCommandTasklet"  
              properties: { command: "echo hello" timeout: 5000}  
             }  
           }  
         }  
        ]  
       }  
     }  
   directory: {  
     #BEAN id:"directory" class:"org.springframework.core.io.FileSystemResource"  
     constructor-args: ["target/test-outputs/test-dir"]  
   }    
 }  

... Not a huge difference, but it would make reorganizing and moving object chunks around without worrying about breaking the commas in a list, or the fields inside an object. I think the parser would be about the same, no impacts to speed. But JSON the format spec, that ship has sailed... Maybe it looks too much like S-expr...

Oracle WINS!!!!.... what?

So Oracle has won... something.

I'm scared that Google has won this with a spectacular Oracle pyrrhic victory. But we as software developers may be losing in a big way.

If Oracle gets to copyright a basic rangecheck function, things are going to get really annoying.

I wish I could talk to a copyright judge and make this argument:

"Can you copyright the word 'is'?" (I assume no)

"Can you copyright the words 'greater than'?" (again I assume no)

"Can you copyright the words 'greater than this but less than that'?" (again I assume no)

And really, right there, you have pseudocode for rangecheck. For the java version, well, basically, you're just with a dialect translations: "Can you copyright the words 'superieure a cette mais inferieure a celle'?" (French google translate, and again I assume no).

I mean, it's not even a quote. There is no depth of meaning, or abstract reference, or hidden commentary. It is a direct request statement, basic functional language. How can that be copyrighted?

I mean, imagine the lawsuits that come out of this. Patent armories don't help for defense. Only writing tons and tons of library code and copyrighting it. You might have tons of excess software written just so they can sue other people for doing similar stuff. 

Windows 7 File Explorer and Search: WTF?

This begins to make me question the fundamental information freedom of the internet and the astroturfing ability of major corporations.

Windows 7 gets sooooo much love. Okay, you finally cleaned up the kernel. Well, we'll see. At work I still have a dozen security nanny applications. But the desktop. What the hell? People say Microsoft has a great research division and tons of usability people. WHERE ARE THEY?

The Windows 7 tendency to hide the Menu in every application. WHAT THE HELL? Why? Why? Whhyyyy? You're relying on people to know to press ALT to get to the menu? Does microsoft not want people to use anything except toolbars in applications? Toolbars rely in intuitive icon design, and intuitive icon design hasn't even left the stone age. 40 years of GUIs and 20 years of the web, and icons still are incomprehensible until maybe, possibly, once you've clicked on the magic button to see what it does, only then may you understand what an open door symbol actually means in some random application. You need the menu, you idiots.

The main toolbar yanked out so many features from the XP toolbar, it isn't even funny. Not having a folder-based organization capability for nesting your start menu links? Am I the only one that had dozens of environment-specific and project-specific links for SSH, html pages, documentation, etc that I would organize in the start menu for two-click access? I'm stuck dragging some folder called "Launch" to the toolbar, and since they wont allow you to drag around the order, guess what? I have to do:

000-link1

010-link2

011-link3

020-link4

Old School BASIC programmers should be nodding their heads right now.

The search functions. I used advanced search and find-in-files a lot. A LOT. Where are they? Gone? And when I search for a file that's in a bunch of deep folders, it gives me four results... and no way to resize the columns so I can see what folder they are in:

That is so bad. Soooooooooooooo bad. Basically, Microsoft is begging everyone to install Google Desktop Search. Oh yeah, and trust us with Bing, we really know how to make search work. See how well we did it on the desktop? Idiots.

Other random crap on the Explorer: As you navigate down the folder tree on the right pane, it doesn't auto-expand the tree in the left pane? WHY NOT? I will give them some cudos for the breadcrumb path. That's not bad. And getting rid of most of the "My " folders and just doing , such as Pictures Videos Music, etc. Hey, it only took you 10 fucking years to stop doing that. Morons. They still do ProgramFiles though. Facepalm.

It's like they wanted to do half of what Nautilus does on Gnome, but got in a huge argument and just stopped finishing it. Basically, it's like a cake being cooked by divorcing parents that spent the entire time making it screaming at each other, not even noticing it was overcooked, they misspelled your name, and didn't put the right number of candles.

Microsoft continues to not care about their customers, and then play mystified, vulnerable child when people call them on their decades-old bullshit. When your company is basically symbolized by a narcissistic, infantile, manipulative, spoiled brat for 20 years, you've got a problem.

I suppose I shouldn't have been surprised.

Lisp: Show me the Beef.

This is the wendy's moment.

God do people like talking about lisp. How amazing and transcendent it is.

Now, I tried lisp. For one semester of Scheme in my programming languages class, unfortunately taught by a teacher who was unable to communicate to humans, and not because he was foreign.

I never went back. Don't even think about going back. Not even a little. Of course I bombed out of the Math department, and most lisp people are math people.

Still, lisp is beyond hype. It is the most mythical and legendary thing in computers, which is bizarre since usually the subject of such things has passed in antiquity. Lisp is right there. Go ahead, there's a dozen implementations. Even a JVM one. The legendary power, right there.

Here's the catch. And this applies to haskell too: WHERE ARE THE APPS? I've heard ludicrous stories of lisp hackers bragging 100x productivity over other languages.

Okay.

Where are the apps?

C begat the UNIX operating system, DOOM, databases, and many office suites. That is a serious software resume.

What has lisp given us? Emacs? Anything else? Anything?

Java doesn't have as amazing a resume as C does, but it does run huge numbers of web sites. Those are killer apps in their own right, transforming your life. How many sites are written in Lisp? That should be some low-hanging fruit. Nope, ruby beat you to that.

What is apparent after decades, let me repeat, _decades_ of existence, through the expansion of computing power by a factor of 1000, lisp has not delivered on its legend. Not even minimally.

Instead, what is apparent is that it is a cult language. This comparison is so appropriate, since the cult of lisp subdivides into even more subcults, even down to the individual. Between the non-infix notation, parentheses, macros, individually produced programming paradigms and features, one man's lisp code is unreadable by another.

If lisp was the most freedom in programming possible, then it used its freedom to shoot itself.

I'll grant the lispers this: if you write lisp, your IQ and ability are measurably above other programmers. And that is the problem with lisp. For every story about the lone lisper beating an entire competing programming department's output in some circumstance, I can't distinguish between the lone genius producing a lot of software in any language/ecosystem from the language/ecosystem itself.

Everyone knows that a single smart programmer can often beat the output of 5-10 average people having to write specs, communicate, have status meetings, status reports, agree on interfaces, deal with different communication vocabularies, and different abilities.

But it just doesn't scale. Lisp doesn't scale. Lisp programmers don't scale. Lisp programs don't scale.

And that's why the crowning achievement of Lisp is a text editor.