Hacker Newsnew | past | comments | ask | show | jobs | submit | barbudorojo's commentslogin

The day that right be implemented I will cut my red beard.


Thanks, thinking twice perhaps HN could be both: a thread to spawn spices and at the same time a threat to them. As we all know Knowledge is a double-edged sword.


Recently in this post (*) I was talking about an idea, openlag, I was suggesting a similar model for microsoft and Revolutions Analytics, It seems I nail it.

https://groups.google.com/forum/#!topic/qilang/BPL-iRweRpk

Microsoft loves linux, What about a new name: OpenWinds?


Interesting, I've been thinking about something like "openlag" lately. It seems like an ideal compromise between the need to make money and the desire to open source everything.

When I've been thinking about it, I was considering a much shorter period of time than three years, though, something more like 3-6 month periods, so your competitive edge comes from the newest features, and anything older is Open.

I feel like it would work really well with a premium SaaS model- open source everything that's free to everyone, and have a reserved feature set that's only for paying customers. Paying customers get new features first, and eventually, everyone gets them.

Of course, at some point, you might shoot yourself in the foot by making enough of the app free and open source that no one will want to pay for whatever you've been developing lately. You also, of course, have to always have compelling new stuff coming out to keep subscribers.

I definitely don't think it's viable for every project, or even most projects, but "openlag" definitely seems like it has a place.


I know Ghostscript was released under that model, maybe it still is.


Thank, that is interesting, to solve it: The lagged software should be given patch to critical bugs as soon as they are available, and the time lag for some products could be something like six months depending on the product. That is the company should provide patch for the critical bugs in the old version if such patch are available or help to solve that. The idea is that the company only keep the advantage of new features not taking advantage of critical bugs to sell the new version.


I wish you the best too.


The author has taken a great care to communicate his ideas clearly in such a way that is a pleasure to read it. Very well done!


What I don't like about Nim is that there is not a repl. In Lisp and Clojure you don't need to compile things.

Could someone give a brief comparison between Clojure and Nim? Let's suppose that we implement Clojure in Nim is this a crazy idea?, What about implementing Shen in Nim?. Many people complain because sbcl is not easy to use with C++ libraries, could an implementation in Nim amilliorate those problems?. Many more questions arise but those mentioned are enough.


Well, there is a REPL, but it's not that great:

    $ nim i
    >>> for i in 0..10:
    ...   echo "Hello World"[0..i]
    ...
    H
    He
    Hel
    Hell
    Hello
    Hello 
    Hello W
    Hello Wo
    Hello Wor
    Hello Worl
    Hello World
To use up/down keys, build the Nim compiler with "./koch boot -d:release -d:useGnuReadline" or run "rlwrap nim i" instead.

Edit: It's even buggier than I remembered, best avoid it and use "nim -r c file" instead.


What bugs or things-that-are-not-great have you run into with Nim's REPL?


It seems that you can't use any libraries. After using import it doesn't work anymore.


The closest thing to what you're asking about is Pixie [1], which is a Clojure-like language implemented in Pypy's RPython.

[1] https://github.com/pixie-lang/pixie

It'd be possible to implement a Clojure in Nim, you'd just have to port the datastructures and enough primitives to bootstrap the language core (see core.clj, Clojurescript's core.clj, Pixie's stdlib.pxi).


Thanks, now I feel I have done something useful posting here. (I have never bought any CS book or chip in any money to any project).


The author was looking for help to develop a minimal battery of tests that any new implementation should have to pass, but there were no voluntaries. Anyway, I think that becoming BSD can help to gather more souls.


Before I checked out of the project he was talking about a test suite, but was firm on not changing the license.

If it goes through, it would indeed make a drastic change, although it could take a long time before the brand damage is repaired.


The current licensing doesn't has a name, the author states in the html page of the standard certain restrictions to fork the code, it has to pass some test, but those tests are not clearly defined and there are other restrictions that move people away from Shen. Choosing a BSD license solve the problem of giving a clear answer to the license of Shen and promotes cooperation.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: