KludgeCode

is Ben Rudgers

My Failed Startup: Part B – KludgeOmatic Now on Github

I joined Hacker News on May 24, 2010 [1102 Days ago] – about five months after the collapse of my startup dreams. It’s taken three years to get the point of open source – yes the announcement of KludgeOmatic would be embarrassing if I hadn’t moved so far away from that point.

Anyway, part of today’s exercise was to set up a Github account and to push KludgeOmatic source code onto it. Here is the link for anyone interested:

https://github.com/brudgers/KludgeOmatic

My Failed Startup: Part A

I had a failed startup [in the weak sense] and didn’t know it until I started blogging.

A few weeks ago, as I was writing the first posts about the Vectorscript projects I created, I suddenly was struck by the fact that I had had a failed startup (to some degree). Recognizing it was an important lesson, and has allowed me to move forward mentally. In no small part, this is because I am impressed by what I was trying to do, and the quality [relative to my own picture of my abilities] of the code that I wrote.

From 2007 through 2010, amidst a lot of trolling and ranting and arguing on the Vectorworks Community Board, I came up with a few good ideas. But my frustration and bad internet habits* were inappropriate, and got me banned. Got banned from push-pullbar2 also about the same time. The Usenet in me dies slowly. The ban from Vectorworks Community Board happened just as I was getting up to speed writing Vectorscript regularly. It also happened just as I was about to announce the KludgeOmatic – a really useful scripting tool running on top of Vectorscript.

As I’ve mentioned earlier, Vectorworks does not include a simple way of creating “command macros” or “simple scripts.” Everything has to be compiled, so everything is hard coded, and has to have a name. Throw in the fact that there is no command line interface, and the overhead of creating a new command entails dealing with drop down menus at a minimum and creating icons if continuous visual access is required – in other words, if you want a button.

At the time, I wouldn’t have described it this way, but the KludgeOmatic implements a domain specific language by creating an evaluator in Vectorscript – Vectorscript, unlike AutoLisp lacks the ability to evaluate itself. Unsurprising given that Vectorscript is based on Pascal (which also indicates the blub love of its designers [I cannot help my self but to criticize Vectorworks as software].

The data structure for the evaluator is a Vectorworks Worksheet – bascially a simple spreadsheet. The KludgeOmatic, reads a row from the table and executes it’s commands. There are flags so that entities can be selected, or the entire line can be skipped (i.e. commented out for rapid development). Overall, it’s pretty fucking simple. So simple, I remain surprised that nobody  had come up with it.

Here is the readme [File dated 1/18/2010]:

What is KludgeOMatic 1.0?
KludgeOMatic 1.0 is a tool for making Command Macro’s.

What does that mean?
KludgeOMatic 1.0 runs a sequence of Menu Commands and more importantly lets you easily edit that sequence from a single worksheet without having to write, compile, and debug Vectorscript.

How much Vectorscript do I have to Know?
If you can look up a Menu Command Name and its index in the VectorScript Appendix you know enough.  If you can look up a Menu Chunk and its index in the VectorScript Appendix, you can utilize the full capacity of KludgeOMatic 1.0.

How do I use KludgeOMatic 1.0 ?
KludgeOmatic 1.0 consists of two parts.

Part One is the “Com.KludgeOMatic1.0.Demo”  Menu Item. Select it and KludgeOMatic runs.

Part Two is the worksheet “KludgeWorksheet.”  You edit this to make KludgeOMatic do what you want.

Rows:

  • The Row1 of KludgeWorksheet tells you what type of value each cell should have.
  • The Row2 and all following rows are arguments processed by the KludgeOMatic Script.

Columns:

  • Column A is an integer. If the value is greater than Zero, then KludgeOMatic will ignore the line – way cool because you can delete commands from your Macro temporarily!
  • Column B is the name of the menu command to run. Obvious ones are “select all,” “move,” “rotate,” “objects from polyline,” etc. Some menu command names are not obvious but you can look them up in the VectorScript Appendix.
  • Column C is an integer and the index of the menu command in Column B. The index is normally equal to zero but if you are using a menu chunk in Column B it can have other values. For Menu Chunks and their indexes see the VectorScript appendix.
  • Column D is an integer. If the value is greater than Zero, then KludgeOMatic will terminate without executing the next line – way cool because you can delete commands from your Macro temporarily, like for debugging!

Is there a Demo Version available?
Yes.  It is full of annoying popups and delays. It only executes four argument Rows. I was thinking of making it only run on Mondays, but I didn’t.

Download the demo here:  http://brudgers.com/arefaq/arefaq-public-docs/Com.KludgeOMatic1.0.Demo.zip

How do I install the Demo Version?
Copy Com.KludgeOmatic1.0.Demo.vsm to your Vectorworks Plug-ins folder.

Create a new drawing in Vectorworks.

Go to File ->Import–>Import VectorScript

Import the File “Drawing KludgeOmatic Demo.txt” into the new drawing.  This creates the worksheet “KludgeWorksheet” and some entities.

What is the difference between the Demo Version and the Full Version?
You mean other than the annoying popups and delays?  The Full Version can process as many worksheet rows as you can throw at it up to whatever limits Vectorworks imposes.

Any other Differences between the Full Version and the Demo Version?

The full version is Vectorworks Serial Number specific.

How Much does the Full Version of KludgeOmatic 1.0 cost?

US $45.00.

How do I order it?

Email payment via Paypal to Payments@KludgeCode.com.

Include the last six digits of your Vectorworks serial number.

Allow up to three business days for fulfillment.

OK, But What are the Coolest things about KludgeOMatic 1.0?

You can keep KludgeWorksheet open for editing while you run the KludgeOMatic 1.0 Script, change parameters and run the script again.

You can use “custom selection” to add or delete named items.   Try the 2d locus “center of rotation” in the demo version, then rotate around it.

*Something I am working to change because participating on HN is rewarding and requires a higher standard of conduct. It’s also more fun to work on writing really well rather than just better than a typical internet user.

Remarks: Epigram 15

“Everything should be built top-down, except the first time.”

Buildings start from the foundation and work their way up. Once they have a roof, then the interior is finished from the top down – or at least this is the good practice for multistory commercial spaces. Finishes and equipment are heavy, causing floor surfaces to deflect and the overall building to deform. Using a different sequence of construction can create bulging drywall and partition studs on the lower floors as upper floors get loaded.

Foundations get laid depending on the condition of the land, building height arises from budgets and regulations and the owner’s [architectural] program. There is little benefit to creating a door schedule and determining hardware sets early on in the process – it’s premature optimization.*

One doesn’t begin writing their Hamlet, by thinking up the phrase “To be or not to be.” The starting point is the history of Denmark, not the actors’ lines. The high level structures fall out of the constraints – and of course, high level and low level are slippery. Is a five act dramatic structure at the top or bottom? Or is it the state frame?

The issue with formalizing top-down structures is that they don’t recognize their closure within a “lexical scope.” The design of a building is constrained by the land, its features occur at a higher or lower level [depending on one’s assigned position within the debate].

* How do drawing templates [programming frameworks] fit into ideas about premature optimization? It seems that in one sense, it is like selecting a site – you have to build somewhere. On the other hand, can you really choose a programming framework – or language – before I have fully understood the problem? Well I suppose if I project myself and my knowledge of programming languages and techniques into the problem definition.

Musings on FOSS: Part A

I was having an unproductive discussion on HN about FOSS, so I thought I would write about it a bit this morning.

In the long run GPL is a step backward from the public domain. It complects ideas with legal overhead. It forms a closure. It creates state. GPL is intellectual property all the way down. It uses the same logic. Relies on the same legal system.


  >(define (license terms)
     (terms))
  >(license 'GPL)
  GPL
  >(license 'Apache)
  Apache
  >(license 'GoogleEULA)
  GoogleEULA 

The structure is the same, all that’s different is the input values. This is not to say that values are not important, and to the extent discussions about FOSS are about expressing one’s values, they are interesting and important. The issue is that the expression of one’s values often gets conflated with commercial competition as commercial competition – it moves from a space of moral choice to a space that is amoral.

What it doesn’t do is free authors from future legal action. The courts have yet to fully determine what constitutes making the source available. Most modern practice does not conform with the original intent – people are getting by with “Well it’s on the web.” How is it available if the IP address of the repository is blocked by commercial or governmental interests? The idea that a link is “including” seems really weak.

The other long term issue is with standards of care as programmers become, as is inevitable, increasingly liable for their work when it causes public harm. Patent Medicine had its epoch. Then came regulation. Orville and Wilbur could sell whatever aircraft they dreamed up, today the FAA has a say in what makes a plane airworthy.

The problem with open source from a professional liability standpoint is that it is work product, not instruments of service. Saying “all software has bugs” is not going to be enough to blow away a specific bug which has caused measurable harm. The hold harmless clauses of GPL do not extend to a client unless written into the agreement between the programmer and client.

Philosophical Musings:

The lisp code reveals a way of saying something interesting aboutt the type of concepts we attach to licenses. The ability to deal with symbols allows the semantics of “license” to be embedded in the code snippet in a way that “foo” cannot do.

Remarks: Epigram 14

This is part of a writing exercise around Alan Perlis‘s Epigrams in Programming.

“In the long run every program becomes rococo, then rubble.”

Rococo comes after the “baroque” and this epigram is inherently about succession and the mortality of intellectual models – I cannot help but chase the pun.

One of the distinguishing features of the Rococo is its asymmetry. Like the fat man and his wife upon the teeter-totter, balance is only achieved by careful attention to levers and fulcrums. Workable in the short-term perhaps, but a long term maintenance is messy. Messy as in a feeding tube for the fat man so as to maintain his weight because down time to adjust the teeter-totter itself creates issues with customers.

Vectorworks is rococo. Features get added ex cathedra, but the core architectural shortcomings never get addressed (it is as if Emacs refused to acknowledge the problem of global scope as a matter of principle). Thus Vectorworks remains locked in the 2D hybrid model which was cutting edge in 1989. Standard Vectorscripts developed by Nemetschek remain unshared with users who might actually improve them, and would certainly learn from them.

The lesson of Facebook, AutoCad and Sketchup is that commercial software can thrive if it is seen as a platform for developers. To boot, giving developers and users more power is probably more fun and rewarding as employment.

Emacs is the quintessential baroque application. Overall balance is achieved by letting a bazaar of user generated elisp features grow and thrive around the Cathedral built upon the C Programming Language. It has email [implemented in a subset of Common Lisp, no less] because the users created it, not by fiat or in response to the VP of marketing.

The ultimate baroque system is the web. It’s lesson is standards create a platform for innovation. Like ECMAscript [JavaScript] those innovations can themselves be standardized, and thus allow further innovation.

Documenting versus Commenting

This post was written as a response to this thread on HN.

I am reading two introductory computer programming texts simultaneously, and have been thinking about comments recently, and your post brought them to a head. Structure and Interpretation of Computer Programs gives example code with no comments. Quite reasonably questions of commenting style are left out for narrative flow – magic is hard enough, no need to bring in religion.

On the other hand, How to Design Programs has an explicit commenting format. It’s design method formally starts with comments.

The question which has been kicking around my mind is, is it helpful to think about commenting and documenting as two different types of activity? And here I am inclined to be a splitter. Documentation describes the unit from the outside. It addresses the question, how do I use this black box? Comments address a different set of questions about the implementation, e.g.why did I use an array instead of a hash, or that a code block needs dekludging. Commenting is providing information that is irrelevant to the use of the function.

Yes, they slide together. A kludge may make a code block perform so poorly as to make it unsuitable for the user. My thought is that it may be helpful to think of commenting and documenting as separate mental activities.

Remarks: Epigram 13

This is part of a writing exercise around Alan Perlis‘s Epigrams in Programming.

“If two people write the same program, each should be put into micro-code then they most certainly will not be the same”

Hesperus had a mortal father accursed to kill his wife with his divine gifts, Phosphorus was the son of a god and is also known as Lucifer. Frame of reference is everything. Neither Hesperus nor Phosphorus is Venus when we are storytelling.

Der Morgenstern = Der Abendstern

Hesperus is Phosphorus only at one abstraction layer. That is where Frege worked. Otherwise, the equality of morningstar and eveningstar is an implementation detail. It is only the black boxes which we can be assured are equal. Dr. Morgenstern comes to the office early to write his code in C. Dr. Abendstern stays late and enjoys assembly. Each creates a program that will tell them the best time for viewing Venus.

One or the other or both or neither program may have been written with an eye toward being put into MicroCode – the epigram shows its age a bit here, who would think of their program being treated thus, these days? The number of people programming today is mind boggling compared to the time at which Perlis wrote.

Is there a parable here about object orientation? Do we want one, two or three ways to represent the astronomical object? It depends on how important hounds and javelins are. The canonical automobile object is given four wheels in the canonical object example. Why? Four wheels is one of the least interesting features of a car and the cases where one flat tire needs to be distinguished from two simultaneous flat tires are rare.

[It is not that I have slowed my writing on the Epigrams, it is that I have slowed my publishing of them on the blog. It allows me more time to gain an understanding of the ideas about which Perlis was writing. The exercise is the writing, not the publishing]

[First draft written in Emacs html-mode!]

Remarks on From OOP to Lisp Part A

What was interesting was that I used Emacs to type both code examples – the first time I’ve tried to use Emacs as a productivity tool. And it really worked well – formatting between languages, switching buffers, auto-completion, just about everything I tried – holding control rather than shift when typing curly braces was a bit disorienting. But then again, being horribly disoriented is nature of learning Emacs.

Currently, I am using the package LispCabinet available from SourceForge, so it’s got some bells and whistles [alas no tits, but it doesn’t cost $300 either]. Lisp Cabinet is designed for Windows, so don’t say you weren’t warned.

The key to learning Emacs for me is learning the “commands” rather than the shortcuts – a “command” being a function which invokes (interactive) and therefore can be called as <M-x ?>.  So I used <M-x scheme-mode> and <M-x c-mode> on each of my buffers – actually I started the SICP example in <M-x lisp-mode> but define was not behaving idiomatically.

The command paradigm gives me somewhere to hang mnemonics. <M-x delete-window> is what I want to do. It comes ontologically before the <C-x 0> which executes it. Just as my observation of the state of the windows comes prior to my wanting to delete one. During the learning process, shortcuts create impedance in the processing of  our wants into commands because we do not yet have the vocabulary to describe what we want to do.

 Page 3 of 8 « 1  2  3  4  5 » ...  Last »