Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

December 6, 2014

Why my book can be downloaded for free

Filed under: Open Access,Perl,Publishing — Patrick Durusau @ 6:49 am

Why my book can be downloaded for free by Mark Dominus.

From the post:

People are frequently surprised that my book, Higher-Order Perl, is available as a free download from my web site. They ask if it spoiled my sales, or if it was hard to convince the publisher. No and no.

I sent the HOP proposal to five publishers, expecting that two or three would turn it down, and that I would pick from the remaining two or three, but somewhat to my dismay, all five offered to publish it, and I had to decide who.

One of the five publishers was Morgan Kaufmann. I had never heard of Morgan Kaufmann, but one day around 2002 I was reading the web site of Philip Greenspun. Greenspun was incredibly grouchy. He found fault with everything. But he had nothing but praise for Morgan Kaufmann. I thought that if Morgan Kaufmann had pleased Greenspun, who was nearly impossible to please, then they must be really good, so I sent them the proposal. (They eventually published the book, and did a superb job; I have never regretted choosing them.)

But not only Morgan Kaufmann but four other publishers had offered to publish the book. So I asked a number of people for advice. I happened to be in London one week and Greenspun was giving a talk there, which I went to see. After the talk I introduced myself and asked for his advice about picking the publisher.

Access to “free” electronic versions is on its way to becoming a norm, at least with some computer science publishers. Cambridge University Press, CUP, with Data Mining and Analysis: Fundamental Concepts and Algorithms and Basic Category Theory comes to mind.

Other publishers with similar policies? Yes, I know there are CS publishers who want to make free with content of others, not so much with their own. Not the same thing.

I first saw this in a tweet by Julia Evans.

October 22, 2012

REST::Neo4p – A Perl “OGM”

Filed under: Graphs,Neo4j,Perl — Patrick Durusau @ 4:13 am

REST::Neo4p – A Perl “OGM”

From the post:

This is a guest post by Mark A. Jensen, a DC area bioinformatics scientist. Thanks a lot Mark for writing the impressive Neo4j Perl library and taking the time to documenting it thoroughly.

You might call REST::Neo4p an “Object-Graph Mapping”. It uses the Neo4j REST API at its foundation to interact with Neo4j, but what makes REST::Neo4p “Perly” is the object oriented approach. Creating node, relationship, or index objects is equivalent to looking them up in the graph database and, for nodes and relationships, creating them if they are not present. Updating the objects by setting properties or relationships results in the same actions in the database, and returns errors when these actions are proscribed by Neo4j. At the same time, object creation attempts to be as lazy as possible, so that only the portion of the database you are working with is represented in memory.

The idea is that working with the database is accomplished by using Perl5 objects in a Perl person’s favorite way. Despite the modules’ “REST” namespace, the developer should almost never need to deal with the actual REST calls or the building of URLs herself. The design uses the amazingly complete and consistent self-describing information in the Neo4j REST API responses to keep URLs under the hood.

A start on a Perl interface to Neo4j.

I am sure comments, testing and suggestions are welcome.

September 5, 2012

Machine Learning in All Languages: Introduction

Filed under: Javascript,Machine Learning,Perl,PHP,Ruby — Patrick Durusau @ 4:20 pm

Machine Learning in All Languages: Introduction by Burak Kanber.

From the post:

I love machine learning algorithms. I’ve taught classes and seminars and given talks on ML. The subject is fascinating to me, but like all skills fascination simply isn’t enough. To get good at something, you need to practice!

I also happen to be a PHP and Javascript developer. I’ve taught classes on both of these as well — but like any decent software engineer I have experience with Ruby, Python, Perl, and C. I just prefer PHP and JS. Before you flame PHP, I’ll just say that while it has its problems, I like it because it gets stuff done.

Whenever I say that Tidal Labs’ ML algorithms are in PHP, they look at me funny and ask me how it’s possible. Simple: it’s possible to write ML algorithms in just about any language. Most people just don’t care the learn the fundamentals strongly enough that they can write an algorithm from scratch. Instead, they rely on Python libraries to do the work for them, and end up not truly grasping what’s happening inside the black box.

Through this series of articles, I’ll teach you the fundamental machine learning algorithms in a variety of languages, including:

  • PHP
  • Javascript
  • Perl
  • C
  • Ruby

Just started so too soon to comment but thought it might be of interest.

June 17, 2012

Neo4j [Perl client for Neo4j]

Filed under: Neo4j,Perl — Patrick Durusau @ 3:45 pm

Neo4j [Perl client for Neo4j]

One of my daily searches turned up:

Neo4j – A client for the Neo4j graph database

Perl client for Neo4j. A very early version, Neo4j-0.01_01.

Neo4j is increases in popularity by leaps and bounds. So are the number of clients in a variety of languages.

If the string “Neo4j” is reserved for the graph software from the Neo4j project and some other string for software to use with it, searching for both additional software and the core package will be enhanced.

Imagine the confusion if dozens of clients are all called “Neo4j” and you are searching for email or newsgroup reports on some issue.

Semantic confusion is going to happen. I don’t mean to imply otherwise.

But let’s not help it along if we can avoid it.

November 15, 2011

Lucy (not in the sky with diamonds)

Filed under: Lucy,Perl — Patrick Durusau @ 7:57 pm

Lucy (not in the sky with diamonds)

From the overview:

Apache Lucy is full-text search engine library written in C and targeted at dynamic languages. It is a “loose C” port of Apache Lucene™, a search engine library for Java.

From the FAQ:

Are Lucy and Lucene compatible?

No. Lucy is a “loose” port of Lucene designed to take full advantage of C’s unique feature set, rather than a line-by-line translation from Java. The two libraries are not compatible in terms of either file format or API, and there are no plans to establish such compatibility.

Is Lucy faster than Lucene? It’s written in C, after all.

That depends. As of this writing, Lucy launches faster than Lucene thanks to tighter integration with the system IO cache, but Lucene is faster in terms of raw indexing and search throughput once it gets going. These differences reflect the distinct priorities of the most active developers within the Lucy and Lucene communities more than anything else.

Does Lucy provide a search server like Solr?

Lucy is a low-level library, like Lucene. We’d like to provide a search server eventually, but it will likely be a thin wrapper rather than a comprehensive application like Solr. The low-level capabilities are our core mission.

Why don’t you use Swig?

A major design goal of Lucy is to present bindings which are as idiomatic as possible so that our users feel as though they are programming in their native language and not in C. Swig is a great tool, but it does not offer support for many of the features which make Lucy so user friendly: subclassing, named parameters, default argument values, etc.

I poked around in the former KinoSearch archives, does “dynamic languages” = Perl? Just curious.

October 18, 2011

ack

Filed under: Perl,Regex — Patrick Durusau @ 2:41 pm

ack

From the webpage:

ack is a tool like grep, designed for programmers with large trees of heterogeneous source code.

ack is written purely in Perl, and takes advantage of the power of Perl’s regular expressions.

It is said to be “pure Perl” so Robert shouldn’t have any problems running it on Windows. 😉

Seriously, the more I think about something Lars Marius said to me years ago, about it all being about string matching, the more that rings true.

Granting that we attach semantics to the results of that string matching but insofar as our machines are concerned, it’s just strings. We may have defined complex processing for strings, but they remain, so long as they are not viewed by us, simply strings.

(What I remember of conversations, remarks is always subject to correction by others who were present. I am sure their memories are better than mine.)

Powered by WordPress