analysis - Javier Neira on Diigo

06 Dec 09

02 Dec 09

ongoing · Concur.next — Eleven Theses on Clojure

www.tbray.org/...Clojure-Theses - Preview

clojure analysis

It’s the Best Lisp Ever
I’m fully prepared to admit that this is a shortcoming in myself
not Lisp, but I think the shortcoming is widely shared.
7 more annotations...
- I think I really totally understand the value of being
  homoiconic, and
  the awesome power of macros, and the notion of the reader. I want to like
  Lisp; but I think readability is an insanely important characteristic in
  programming systems.
- Agents are not
  actors nor are they
  processes in either the Operating-System or Erlang senses. I’m not actually
  sure how big a difference that makes; my suspicion is that programmers
  probably think about using all three in about the same way, and that’s OK.
- By
  removing concurrency. Send functions to an agent and they’ll get executed one
  at a time in whatever order, taking the agent variable as their first
  argument, replacing its value with their output.
- Considerably simpler, and nothing (concurrency-wise) can go wrong.
- you
  can’t have a send inside a send.
- Clojure’s concurrency tools reduced
  the elapsed run-time by a factor of four on an eight-core system, with a very
  moderate amount of easy-to-read (for Lisp) code.
- As I’ve already observed, the Clojure community is terrific; we’ll see how
  well that stands the test of time.

30 Nov 09

The Programmer's Paradox: Spaghetti Code

theprogrammersparadox.blogspot.com/...spaghetti-code.html - Preview

programming bestpractices kiss tdd analysis

4. Fixing one bug creates several more.
Fundamental Laws of Spaghetti Code:

1. You can't understand it just by looking at it.

2. Repetitive code will always fall out of synchronization.

3. The work will always gets harder and slower as it progresses.

4. Fixing one bug creates several more.

5. You can't enhance the code if you are spending all of your time fixing the bugs.
24 more annotations...
- You can't understand it just by looking at it.
- 4. Fixing one bug creates several more.
- 4. Fixing one bug creates several more.
- If we are interested in a a reasonable definition for spaghetti code, it would have to be any code were the internal structure is way more complex than necessary. Where the complexity of the code
- It's not the syntax itself, but what it obscures from the processing that matters.
- That is, if you hide the "right stuff" (coming up from a lower level), then the code appears far more readable. If you hide the "wrong stuff", then it becomes impossible to tell exactly what is going on with the code.
- The last thing programs need is unnecessary complexity.
- I'm not sure that's an entirely correct statement. It's more like: if you're skilled, and you should be able to understand it, but you don't then it is probably over-complicated.
- THE PERILS OF DUPLICATION
  
  2. Repetitive code will always fall out of synchronization.
- . When we do this, it increases the probability that some future set of changes will cause a bug because two different "sources" of the same information that are no longer the same.
- 3. The work will always get harder and slower as it progresses.
- What's really funny is how many excuses people will make for not cleaning up the code.
- "history"
- "backwards-compatibility"
- Anytime a group of programmers generates more bugs then they fix, it is either because they don't have the necessary experience to understand and fix the code, or that the code itself is hopelessly scrambled.
- They just move the bugs around the system.
- The single biggest issue with code is time.
- it is always so hard to hear programmers making excuses about how they don't have enough time to fix something
- Unit tests are just more code in the system that are going to be wrong, need fixing, must be updated, and take time.
- recovering time lost to maintaining spaghetti code should be the first priority of any development project.
- It's a critically bad mistake to not fix code early on
- I do think it is actually easier for programmers to build over-complicated code, than it is for them to build simple and elegant code.
- Programmers have big egos, and they like to work on the hard projects. So, even if their task isn't particularly hard, they'll do everything in their power to make it as difficult and hard as possible. It's a common weakness.
- They are instead the ones that make all of their solutions look as simple and trivial as possible.

26 Nov 09

PicoLisp: A Radical Approach to Application Development

www.picolisp.org/radical - Preview

pico lisp analysis functional programming

Typically { in business applications like ERP or CRM { this is a process of permanent

change.
In an ideal world, software development is only planning { the time spent for

actually writing code should converge towards zero.
7 more annotations...
- the Pico Lisp [1] system evolved from a minimalist Lisp implementation to
  
  a dedicated application server
- Myth 1: Lisp Needs a Compiler
- A modern Lisp needs
  
  a compiler; the interpreter is just a useful add-on, and mainly an interactive debugging
  
  aid. It is too slow and bloated for executing production level programs.
- The source language (Lisp) was transformed
  
  to another language (machine code), with inevitable incompatibilities between dierent
  
  virtual machines.
- some gain in raw execution speed, and compiler
  
  construction is interesting for academic work.
- A Lisp program as an S-Expression forms a tree of executable nodes. The code in these
  
  nodes is typically written in optimized C or assembly, so the task of the interpreter is
  
  simply to pass control from one node to the other. Because many of those built-in lisp
  
  functions are very powerful and do a lot of processing, most of the time is spent in the
  
  nodes. The tree itself functions as a kind of glue.
- Myth 3: Dynamic Binding is Bad

23 Nov 09

El futuro es el contexto: Web pragmática | ReadWriteWeb España

www.readwriteweb.es/...-es-el-contexto-web-pragmatica - Preview

spanish trends pragmatic web analysis sociology

La Web semántica tardará en adquirir valor porque los agentes personales inteligentes capaces de procesar estos datos estructurados aún van a tardar en cobrar forma completamente
Mi experiencia en Internet es más significativa y relevante cuando lleva asociados datos de contexto social basados en mi identidad. Esto es la Web pragmática.

22 Nov 09

State of Open Source Java EE Application Servers | Java.net

weblogs.java.net/...ce-java-ee-application-servers - Preview

opensource j2ee container analysis review

Programming and politics: Passing on the Duby

fupeg.blogspot.com/...passing-on-duby.html - Preview

java next compiler runtime library analysis

2.) No runtime library
Now, I can certainly understand Charlie's objection to a runtime library. It is a lot of baggage to drag around. All of the JVM langs have this issue.
2 more annotations...
- you can just include the runtime library of your choice. Pick your own list, hash map, thread pool, and file handler implementations.
- Charlie gave an alternative to this -- leverage the compiler plugins.

20 Nov 09

Don’t Delete – Just Don’t

www.udidahan.com/...dont-delete-just-dont - Preview

crud delete business programming analysis

some important business semantics missing.
As developers discuss the pertinence of using an IsDeleted column in the database to mark deletion, and the way this relates to reporting and auditing concerns is weighed, the core domain concepts rarely get a mention.
4 more annotations...
- Should all previous orders containing that item just disappear?
- We’ve been exposing users to entity-based interfaces with “create, read, update, delete” semantics in them for so long that they have started presenting us requirements using that same language, even though it’s an extremely poor fit.
- his intent is to discontinue the product – not to delete it in any technical sense of the word.
- Orders aren’t deleted – they’re cancelled. There may also be fees incurred if the order is canceled too late.
  
  Employees aren’t deleted – they’re fired (or possibly retired). A compensation package often needs to be handled.
  
  Jobs aren’t deleted – they’re filled (or their requisition is revoked).

Code, Coffee : weblog, Beta - "CRUD's Not The Answer"

www.joshlong.com/...cruds_not_the_answer.html - Preview

crud dao rails persistence architecture analysis

that deletion is rarely, if ever, a valid business state and
that care should be taken in dealing with it.
The idea
that you can annotate a few entity classes and suddenly you have a
model and business logic all taken care.
15 more annotations...
- It's
  now common to expose EntityManagers to the web tier
- Objects in a system have state that has dependencies.
- A lot
  of this stems from the "active objects" or "naked objects" pattern,
  where objects are open books whose state can be mutated on the UI tier
  directly and those changes propagated directly. We tell ourselves that
  we can apply Hibernate validations (or validations in any other ORM
  framework) and that we'll guarantee valid business constraints thus,
  but it rarely works out that way.
- We tell ourselves that
  we can apply Hibernate validations (or validations in any other ORM
  framework) and that we'll guarantee valid business constraints thus,
  but it rarely works out that way.
- Prescribing the valid creation and
  destruction of an object is critical.
- People "forget" how an object is
  created, or destroyed.
- People "forget" how an object is
  created, or destroyed. They forget details.
- Plus, as business evolves, object creation is often only part and
  parcel with a larger process. If a new customer is added to a
  database, and nobody does anything with it, did it really get added?
- but the act of instantiating a Customer object
  and then issuing entityManager.persist( customer ) will
  rarely, if ever, be enough.
- I've seen many projects
  build their models using only a GenericDao<T>
  variant. This is dangerous. Transitions from one state to another
  for an entity can often cost money.
- I've seen many projects
  build their models using only a GenericDao<T>
  variant. This is dangerous
- While the services approach isn't exactly code-generation
  friendly, it can pay off in the long run.
- It's
  easier to build services that express every dependency as a method
  parameter.
- There are several reasons why this works out.
- In these methods, you can do sanity checks,
  care for business cases, handle the state of the various objects and
  not worry about having a transactional resource like an EntityManager or Hibernate Session open in the client thread

19 Nov 09

Code, Coffee : weblog, Beta - "Understanding Go"

www.joshlong.com/...understanding_go.html - Preview

go analysis programming vm

Programming languages tend to come and go, but they all advance basing
their innovation in some small part on their predecessors. Programming
languages have to evolve slowly
They must strike a careful balance, never alienating the
existing community, the legacy base, and always advancing the state of
the art.
5 more annotations...
- Compatibility is a double edged sword.
- Why not the JVM? Would building that kind of infrastructure
  be that hard? What about the LLVM? It seems well suited to working on
  Unix and to handling interop.
- Why could the JVM - which hosts Scala and Clojure - not
  be used to build goroutines. Is there some fundamental flaw that makes
  concurrency on the JVM a non starter? I don't understand.
- For some reason I used VM and runtime interchangeably.
- The main reason they remain inappropriate (for example on real time OSes, or in the embedded space) is the same reason this Go is inappropriate: it's got non predictive garbage collection.

Nokia ante su laberinto | Error500

www.error500.net/...nokia-ante-su-laberinto - Preview

mobile platform analysis iphone nokia symbian android

15 Nov 09

Interfaces vs Inheritance (or, watch out Go!)

www.artima.com/...viewpost.jsp - Preview

inheritance interface oop functional analysis

It is at that moment that I decided to start a public campaign against
inheritance and pro interfaces. Interfaces are the really important
idea, not inheritance,
I also
decided to write a set of articles about the dangers of inheritance
2 more annotations...
- Python has interfaces (starting from Python 2.6) which are
  acceptable but not really what I had in mind.
- It turns out that Go lacks inheritance and it
  has something similar to the kind of interfaces I had in mind for all this
  time.

13 Nov 09

defmacro - The Nature of Lisp

www.defmacro.org/...lisp.html - Preview

lip programming language analysis

"Why on Earth would anyone want to use a language with such
horrific syntax?!"
Nobody could illustrate the usefulness of these features with specific examples because these
techniques are supposedly only useful in large software systems.
16 more annotations...
- My time has not yet come.
- I was baffled. Many extremely intelligent people I knew and had much respect for were
  praising Lisp with almost religious dedication.
- The enlightenment came instantaneously.
- Dozens of times I heard Eric Raymond's statement quoted by different people: "Lisp is worth learning for the
  profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the
  rest of your days, even if you never actually use Lisp itself a lot."
- That very second I became a member of the Lisp cult.
- XML is the all too familiar concept that Lisp
  advocates need so much. It is our bridge to conveying understanding to regular programmers.
- After all is said and done, XML is
  really just a tree serialized to a human readable form
- Anything that can be represented in a tree can be represented in XML and vice
  versa. I hope you understand this idea.
- Any compiler inevitably parses the source code
  into an abstract syntax tree. This isn't surprising since source code is hierarchical: functions contain arguments and blocks of code.
  Blocks of code contain expressions and statements. Expressions contain variables and operators. And so it goes
- then all source code can be converted to XML, right?
- Furthermore, for languages that share common features but use different syntax (which to some extent is true about most mainstream
  languages) we could convert source code from one language to another using XML as an intermediary representation.
- Java2XML
- XML2CPP
- We'd be able to create a whole class of
  programming languages that use uniform syntax, as well as write transformers that convert existing source code to XML.
- Take a good look at the XML version of our "add" function above. How would you
  classify it? Is it data or code?
- Code is also always data! Does it mean that data is also always code?

Databases - A New Frontier

www.defmacro.org/...relational.html - Preview

databases lisp analysis

11 Nov 09

Cerraduras: clojure en español: Sobre java (o por qué no sobre java)

javierneirasanchez.blogspot.com/...a-o-por-que-no-sobre-java.html - Preview

java programming analysis spanish

08 Nov 09

A Neighborhood of Infinity: Memoizing Polymorphic Functions with High School Algebra and Quantifiers

blog.sigfpe.com/...olymorphic-functions-with.html - Preview

programming analysis theory typing algebraic

You can think of a generalized trie for a function type T as a type that's isomorphic to T but doesn't have an arrow '->' anywhere in its definition. It's something that contains all the same information as a function, but as a data structure rather than as a function. Hinze showed how to construct these by using the high school algebra axioms on non-polymorphic types.
You can think of a generalized trie for a function type T as a type that's isomorphic to T but doesn't have an arrow '->' anywhere in its definition. It's something that contains all the same information as a function, but as a data structure rather than as a function.
7 more annotations...
- Polymorphic types are types involving quantification. So to make suitable tries for these we need to add some rules for handling quantifiers to high school algebra.
- When Hinze demonstrated how to construct generalized tries he showed how to make a tree structure that was tailored to the specific types in hand. With polymorphic functions we don't know what types we'll be dealing with, so we need a one-size fits all type. That sounds impossible, but it's not.
- When Hinze demonstrated how to construct generalized tries he showed how to make a tree structure that was tailored to the specific types in hand. With polymorphic functions we don't know what types we'll be dealing with, so we need a one-size fits all type. That sounds impossible, but it's not.
- Suppose F(a) is a type expression involving the symbol a. Then the type ∀a.F(a) can be thought of as being a bit like the product of F(a) for all possible values of a. So ∀a.F(a) is a bit like the imaginary infinite tuple
- Suppose F(a) is a type expression involving the symbol a. Then the type ∀a.F(a) can be thought of as being a bit like the product of F(a) for all possible values of a. So ∀a.F(a) is a bit like the imaginary infinite tuple
- One reason you can think of it this way is that all of the projections exist. So for any type you choose, say B, there is a function (∀a.F(a)) -> F(B). In Haskell the ∀ is written as forall and probably the best known example is the Haskell id function of type forall a. a -> a.
- For any functor F and type n, ∀a. F(a)^aⁿ = F(n)

03 Nov 09

Simplicity is Complicated | Virtuous Code

avdi.org/...simplicity-is-complicated - Preview

programming simplicity analysis

In the name of simplicity, some programmers advocate avoiding "magic" language features they see as complicated and difficult, such as generics, recursion, or metaprogramming.

J2EE design decisions - JavaWorld

www.javaworld.com/...jw-0130-pojo.html - Preview

j2ee design principles analysis

29 Oct 09

JavaScript: The World's Most Misunderstood Programming Language

javascript.crockford.com/javascript.html - Preview

javascript analysis functional

JavaScript:

The World's Most Misunderstood Programming Language
This is misleading because JavaScript has more
in common with functional languages like Lisp or Scheme than with C or Java.
2 more annotations...
- It has arrays instead of lists and objects instead of property
  lists. Functions are first class. It has closures.
  You get lambdas without having to balance all those parens.
- Some argue that JavaScript is not truly object oriented because it
  does not provide information hiding. That is, objects cannot have
  private variables and private methods: All members are public.
  
  But it turns out
  that JavaScript
  objects can have private variables and private methods. (Click here now
  to find out how.) Of course, few understand this because JavaScript is
  the world's most misunderstood programming language.
  
  Some argue that JavaScript is not truly object oriented because it does not
  provide inheritance. But it turns out that JavaScript
  supports not only classical inheritance, but other code reuse patterns as well.

Generalizing -> & ->> - Clojure | Grupos de Google

(defmacro -$>
"Threads the expr through the forms. Inserts x into
the first form at the position marked by the $ symbol.
If the second form is not a list then it behaves as ->.
If there are more forms, inserts the first form into the second
form at the position marked by the $ symbol, etc."
([x form] (if (seq? form)
(let [split (split-with (partial (complement =) '$)
form)]
`(~@(first split) ~x ~@(rest (second split))))
(list form x)))
([x form & more] `(-$> (-$> ~x ~form) ~@more)))

groups.google.com/...2cc0f1f1abe6e1de - Preview

clojure macro -$> analysis

Javier Neira's Library tagged analysis → View Popular

Un informático en el lado del mal: Control de Cuentas de Usuario (I de VI)

ongoing · Concur.next — Eleven Theses on Clojure

The Programmer's Paradox: Spaghetti Code

PicoLisp: A Radical Approach to Application Development

El futuro es el contexto: Web pragmática | ReadWriteWeb España

State of Open Source Java EE Application Servers | Java.net

Programming and politics: Passing on the Duby

Don’t Delete – Just Don’t

Code, Coffee : weblog, Beta - "CRUD's Not The Answer"

Code, Coffee : weblog, Beta - "Understanding Go"

Nokia ante su laberinto | Error500

Interfaces vs Inheritance (or, watch out Go!)

defmacro - The Nature of Lisp

Databases - A New Frontier

Cerraduras: clojure en español: Sobre java (o por qué no sobre java)

A Neighborhood of Infinity: Memoizing Polymorphic Functions with High School Algebra and Quantifiers

Simplicity is Complicated | Virtuous Code

J2EE design decisions - JavaWorld

JavaScript: The World's Most Misunderstood Programming Language

Generalizing -> & ->> - Clojure | Grupos de Google

Selected Tags

Related Tags

Sponsored Links

Top Contributors

Groups interested in analysis

Remembrance

History Teachers

clojure-dev

Bakhtin

Business Intelligence Tool