salboaie

I am curious if there is a coherent approach to modeling attention for long- or medium-term goal following. Currently, LLMs resemble a fish or a small child in their focus and behavior. Robots with such limitations would be strange to work with.

Interesting. If conscience is.. fundamental, than maybe even the future is deciding the past...

Promoses and flow libraries have steep learning curve

Ahh no, I've just submited to HN my new library https://github.com/salboaie/harvests (simpler replacement to promises and flow control libraries)

The Web itself is a distributed system but the personal home pages are not really a social network. We can imagine as possible a system where pages/small apps that you host with different cloud (hosting) providers obey the same rules to form together a distributed social network. This way,you have total control on your pages and apps and not a corporation. Is Facebook doomed today or tomorrow? Everything dies in the end but that simple and powerful implementation (idea) capable to replace Facebook can be years away...

Right, object oriented is not everything, sometimes ifs or switches are just fine.

I would suggest that decision tables, rule engines, workflow, DSLs, even finite automaton and other abstractions etc are better than having many many objects that are avoiding ifs :)

For a start you should read Hackers and painters: http://www.paulgraham.com/hp.html

At least for HN comunity that gives enough menaning, and I like it a lot. From other people, hacker means "cracker".

You have the classical todo MVC on github. In the first days next year I will send to people managing the official todo project but if you get the project, put on a web server, you can quickly run the todo project.

Yes, but what I was looking was a very different beast: Bindings with properties chains, declarative style when possible, typed models with auto-computed expressions, reusable components (controllers/presenters), separation of views from controllers (as little code as possible in views - in shape we have only html with bindings). Our background was Flex with a MVVM framework we created. We tried to replicate it in HTML5 .

The battle is not only between Backbone and Angular, there is place for more innovation. I prefer Angular approach (As you say: "Less code to write means less code to test means less code to debug means less code to maintain. It also means a lesser page-weight at the end of the day." ), but we are putting our passion to create a framework for complex applications (something in line with Angular but with better features) While still beta, we already have models that are doing type checking, better/maintainable code, correctness against asynchronous effects caused partially by the declarative style we love and simplify the code so much,etc: https://github.com/salboaie/shape/

I believe that Angular is still at the level of creating nice sites but not for big applications. We are trying to compensate JS weaknesses with features for big enterprise applications (boring CRUDs, sloppy and not so motivated developers for working on bigger enterprise applications).

We need all possible help from other programmers with code, tests, real life prototypes, help from native English speakers to create good documentation, to get infected with our passion and to speak about the framework to other developers, etc.

I know that it is a hard battle but it is a pleasure to work for such ideas anyway.

I predict that in the end, a declarative one will be the winner, eventually one that will compensate JavaScript weakness. Therefore, we are working to create a framework for complex applications (something in line with Angular but with better features) We have models that are doing type checking, better/maintainable code, correctness against asynchronous effects caused partially by the declarative style we love and simplify the code so much,etc: https://github.com/salboaie/shape/

Software and technology is not a top priority during crisis and other people don't read HN so much :) But on the other hand, a friend of mine recently said that he would invest to create homes for elderly people in Romania (in old communist resorts,in mineral water rich zones,having some infrastructure ready, etc) for West European (eg. German) old people. Cutting costs in West Europe could be a very lucrative business in Romania. Could work fine because of crisis.

I like the idea of creating software that resemble patterns found in nature. I invented 2 directions (not very popular yet, but I like them anyway): 1. organic programming: grow the systems, not build them. This idea lead me to creation of 2 frameworks (one is open source, but beta: https://github.com/salboaie/shape) My original idea about organic programming was about a tight integration of the tools used for developing the program with the program itself. These tools can be used at runtime to customize or even to create new features. This approach have interesting implication on the framework, some good, some not so good but the organic paradigm changed the direction and reduced complexity and arbitrariness of some design decisions. 2. swarming and swarms as better metaphor for asynchronous messages. This idea has very nice implications and I believe that it is an approach that goes towards essential complexity regarding programming with asynchronous messages. For details, asm me or take a look here: https://github.com/salboaie/SwarmESB

Anybody wants to look to another one (not launched, still a beta version, but created with large projects in mind, speed of development and long time maintenance in mind): https://github.com/salboaie/shape ?

I will greatly appreciate your feedback.

Did you know about a "hidden" page: http://news.ycombinator.com/best Looks like an experimental feature to me but it will be nice to have something like this.

Waiting for: http://news.ycombinator.com/best/2012

Interface innovation is not the same thing as "innovation in solving a real problem". The best interface is "no interface" and command line is the best interface for many cases. One day we will automate all system administration (really?) and we will stay in the front of a super control panel for all our servers and services that run in "cloud" but meanwhile command line rules :)

On the server side I'm hardly believe that a SOA like architecture will be largely used. I'm biased because I'm the author of an ESB like systems for working with services even simpler: https://github.com/salboaie/SwarmESB.

The core concept for SwarmESB I call "swarming" that is a method to compose API's in a distributed system. Swarming can be for SOA's orchestration what REST is for SOAP. Introduction: http://www.slideshare.net/salboaie/swarms-introduction

Copy paste from another question :D For my shame . Thank clyfe:

Coding the whole app in JS in the browser and using the server only for proxying data and validation/filtering. See: SproutCore, Cappuccino, Backbone.js, JavaScript.MVC Avi Bryant's "Django is obsolete, but so is everything else" http://python.mirocommunity.org/video/1186/djangocon-2009-dj.... Yehud Katz's http://yehudakatz.com/2010/09/14/heres-to-the-next-3-years/ reply

Looks that I have bad karma ) I read HN daily,but I never contributed with comments or questions,... mmm :)