phzbOx

Maybe I don't understand what you mean by "incompatible dialect". These are simple classes inheriting from list/dict. Basically, it simply add a couple methods to these objects. I.e. You can still use all the idioms/patterns; these are list/dict. I'm not creating a new paradigm, or writing a new language by tweaking the syntax. There's really nothing magic going down here. I.e. you can do

    return List(..).update(..).update(..) 

Instead of;

    l = List(...)
    l.update(...)
    l.update(...)
    return l

You can still use lisp comprehension, itertools, etc. In fact, I could pass a moka.List to your existing code and you wouldn't even notice it. (And you do, it's a mistake that I'd fix).

I do agree that I might have been overkill with some useless methods and I'm thinking about removing them. (I.e. such as 'join' as it's really not needed)

For me, it was using 'cd' without argument. (It takes you back to your ~). Also, learning the various options of grep (-v, -i, -A, -B) made its use really more powerful.

I'm not sure why you created a fake account to answer this but thanks again for your time. You're right that it was built for my own taste using simultaneously other languages (clojure, arc and js for instance). At the end of the day, what's important is that it increases the quality of the code and this is my goal with Moka. This is still in an alpha stage, but I'll definitely tweak it based on good feedback (Like yours) Feel free to drop me a line: phzbox at gmail if you want to continue this discussion.

Thanks for all the good points. To be honest, I'm not sure what you're trying to say. I've been coding in python for years and Moka was built from my annoyance using functional paradigms with the stdlib.

As you clearly showed, Python doesn't have an uniform syntax to deal with this paradigm. I.e. there are lots of different constructs and, as you said, common idioms or patterns. Have you already argued with a Java programmer saying that these 'Design Pattern' are just a limitation of the language.. whereas in Python you'd probably just use a simple Dict (or whatever)? I'm sure you did. I feel the same with the idioms and patterns.

See, in Clojure (And Arc, and even Ruby), there is an uniform syntax.. whereas in Python we've got itertools, list comprehension, builtins map/filter, random builtins functino such as sorted().

I have to agree with you that Moka is not Pythonic in the There's only one way to solve a problem as we add a new way. However, Moka was created because there was so much inconsistent alternatives..

However, Moka is Pythonic in how it behaves. God knows I could have use all nifty hacks to make it behaves magically.. but I chose to take the explicit route by overriding list/dict. I could have used string interpolation for function (See http://osteele.com/sources/javascript/functional/); but instead went the Pythonic way with standard lambda functions. Maybe you are right about the operator keywords shortcut (i.e. using List().keep(operator.eg) instead of List().keep(eg=); However, I still feel it was a way to make it even easier to integrate with existing tools from the stdlib.

Lastly, you said:

    zen: flat is better than nested
    > Dict(a=1, b=2).update(c=3).rem(lambda x, y: x=='a')

^^^^^^^^^^ This is not nested, this is chained.

This, however, is nested: # Taken directly from the itertools stdlib page. next(islice(iterable, n, None, default)

    # Here, this is not nested.. this is chained:
    def logged_user(self):
        return (self.users
                      .keep(User.is_logged) 
                      .keep(lambda u: u.is_active)
                      .map(lambda x: User.objects.get(id=x)))

Optimizing for performance is the next big step of Moka and I understand that it's the breaking point for lots of python developers. So, I'll make sure to work on that and provide realistic benchmarks.

As for the copy, yes it does as it tries to act like a builtin list as much as possible. (In fact, moka.List inherit from list). When it's in immutable state, a new list is returned at each step. If it's in mutable, self[:] = (..) is used.

Thanks for the feedback, these are interesting points. I'd like to clarify a couple of things about your #2 and #3.

    def user_logged(users): > return List(users).all(User.is_logged)
    # If you want per instance:
    def user_logged(users): > return List(users).all(lambda x: x.is_logged())

And, about the "".join; you are right. However, Moka's construct allow you to use whatever you want, i.e.:

    moka.List(['a', 'b']).do(string.join, '').last_value

Or, you can still use:

    ''.join(moka.List(['a', 'b']))

However, about the #1, I have to agree. I've added the saving() recently and had a bad taste about it. The right way to do it might be to make it mutable by default and only toggle it off in certain circumstances.

Please note that everything done by the community is still perfectly usable; in fact, it's even easier to use useful high-level functions.

I.e. map(str, range(1,10)) or List(range(1,10)).map(str); is syntactically different but does the same job.

Cool. I do agree that official guides are sometime annoying as it gives you all the solution instead of just giving you the hint needed to continue. Good job :) Looking forward to see how it progress.

Thanks for the feedback; I agree with you. Here's the reasoning behind these odds choice..

List is-a list, and Dict is-a dict.. and thus, I'd like to make it possible to safely pass these objects to already existing code. If I rename .rem to .remove, I'd break that.

The reason for the chaining saving() is because it's useful to be able to toggle it. For instance:

  self.x = Moka.List(range(1,10)).mutable()  
 
  return (self.x.map(lambda x: x*2)
                      .immutable()
                      .keep(gt=5))

So, basically, you change self.x with the map, but don't necessarily want to change it with the keep().

(I'm not saying it is the right thing, just why it's done that way.)

It's fairly new but feel free to browse the code; it should be pretty straightforward to you. I've tried to provide good examples to make it easy to learn/use on phzbox.com/moka/.

Clickable link for the doc: http://phzbox.com/moka/index.html

Moka is still in an alpha stage; but that being said, I'd love to hear some feedback. Feel free to browse the code, it should be pretty straightforward to any python dev.

You know the question the VCs always ask: "What if google decided to attack your market, what would you do?" I guess it's a sad day for a couple of promising startups.

It's always the eternal "Good for user" vs "Good for programrers". I.e. When creating a new language, one must make choice.. should it be easier to read/use for the coder? Or easier to code from the developer side.

And, if we look carefully in the past, it seems that it always start with the "Easy for coder first" -------> "Easy for user". For example, when the first examples of Ajax came out, it was really hacky and most programmers would have never believed what they'd see today.

So, I think that you are half right with the "introducing complexity in an unstable, unaffordable and insecure client." Maybe with the actual technology and framework, you are right. But I'm certain that in the following months/years, we'll go toward the road of a better UI.

And, I still believe that it's not as hard as people think to make UI update first and update later. 99.9% of the time, the server returns "ok" or something we already knew. In the last 0.01%, we have to choose if we really want to make it to 100%.. but in these rare case, a hard refresh is perfectly fine.

No, but that's not the point. If the web page is telling you "Wait, your email is being sent" and you close your browser, do you expect the email to be sent? Or if it says "Please wait, the document is being saved" and you close the application..

I.e. The point is that asynchronous make it feels smoother. If the browser crashes while data is being transmitted, there's nothing you can do. Ajax, asynchronous or whatever. So, what will happens is the data will be lost. The asynchronous part doesn't resolve all problems.. it just feel faster for the user.

And, by the way, why the ":)" at the end? Is it because you were happy? Personally, I find that a bit provocative. (i.e. in gaming, people would say "You suck :)" or if they'd crush you, they would just say :). It's being bad manner.) But then, if you were happy and just wanted to show it, sorry for this comment.

Well the website is mostly static; that'd be overkill. Maybe the author wanted to use another library to create the documentation automatically. But, you've got a point saying that if it's not your first choice for simple static pages, it's a bit scary to use it for huge production website. I.e. Django might be overkill for a simple static page, but it's still trivial to use it for that.

Well, I don't want to go into deep maths but the chance of creating the same cID is infinitesimal.. so one doesn't have to manage this case graciously. I.e. Just refresh the page or make a soft refresh (clear the models and re-send the data from the db, which isn't huge since that part is already coded for the initial loading). It's not the same as if it had 1/10 chance and you had to be clever to fix it. I mean, even without this problem, it happens from time to time that the best software needs to refresh because of a small bug.

Would using only a CID be a solution?

From the server perspective, it stores the real ID and the CID given by the client. In the extremely rare case where CID could be duplicated, the server could send back an error with an unique CID and the client would update itself.

That way, we're sure the ID is always unique on the server, but the client simply use a cid. In fact, the 'cid' could even be abstracted away by calling it ID. I.e. the server has 2 ids, the server one and the client one.. the client doesn't need to know the server-side one.

The author specifically talks about that in the article saying that you can catch "leaving a page" and notify the user that there's still something pending and data would be lost.

And in the case of a big error, you can either refresh the page.. or clear the models and resend them in json format to stay sync with the server. It might be a little more complicated, but with a good framework, not that much more. I.e. multithreaded code is a pain.. asynchronous or not, it's a pain. And, in the rare case where you really need to wait for the server to answer back, well, use a loader. But there's a difference between using a loader when you absolutely need it, and everywhere. Think of how apps work on the desktop.. everything is lighting fast, but in some rare occasions, it blocks. What is better? Something that always block or something that sometime block?

You pointed a good example of where this wouldn't work. However, you can still make everything else asynchronously fast; and use a loader when it needs to really wait for 5 secs.

For instance, take gmail. Some part might hard to use that way.. for instance, chat communication where you somewhat need to receive the answer of the other person to show it. However, adding labels, deleting a message, etc.. that can all be made asynchronously.

Why programmers are not paid in proportion to their productivity? Because they procrastinate the other 50% of the time! (Obviously, it is a joke. But ironically, we're discussing that on HN...)

If I give you 5M$ now, what would you do? Now, do exactly that, without those 5M$.

Wops, you both are right, thanks for pointing it out. I meant to say dict.get, i.e.

  {'a':1}.get('b',5)

Hell yeah, thank you. I've been so tired of googling up "css background" and click 2-3 website and hope they'd show what I want.

I think the best is a little of both ways. For instance in python:

  x = some_dict['meh']

Will raise if 'meh' doesn't exist. If you believe that 'meh' should be there in your program, it's fine to 'let it raise an exception'.

However, if 'meh' could be there, it's better to use an error style such as:

  x = some_dict.getDefault('meh', 'some-neutral-value')

And continue without raising because there's no need to raise as there's nothing exceptional here.

Ideally, raising an exception should have the meaning "Hey, something is wrong here and I don't know what to do next". And someone in the call hierarchy would handle this and say "Oh, the connection stopped.. that's why it's not working. I'll reconnect and call you again".

And note that this "parent handling" might be way higher than where the problem occurred..

Still, the Emacslisp example would be easier to read/maintain/debug if it was separated in multiple functions.

Small hack: Instead of using "X" for the delete icon, use "×". It looks more like a delete/close button and still avoid the trouble to create an image.

Which ones?

Why all the hate coming from the comments on this page? The guy is offering is time to have fun hacking on a cool project.

Thanks for the feedback. Yes, I totally agree about the performance hit. I'm still thinking about the interface and what methods Moka should provide. After that, I'll make a pass to optimize constructs as much as possible.

I've released a functional python library and I've written the doc with bootstrap (www.phzbox.com/moka/) Was amazed by its simplicity.

Nice features. In what does it make it a "company" rather than a cool side-project? (Don't take it the harsh way, I'm really interested in the answer :)