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

Morgan Stanley is hiring developers at all levels in Montréal, to work on our extremely cool - massively distributed, asynchronous, referentially transparent risk management platform. Multiple teams collaborate on technologies including bitemporal object stores, asynchronous language semantics, compiler development, massively distributed computation, embedded query languages, and declarative reactive UIs. Our focus on core platform development means that our primary clients are not the teams and individuals operating on the financial side, but their end-user application developers, who rely on the services and components we provide.

Location: Montréal, onsite (remote is possible within Québec).

More information: https://youtu.be/V0jJvgiI_xs?t=1469 https://ms.taleo.net/careersection/2/jobdetail.ftl?job=32022... Or contact me directly: peter dot fraenkel at morganstanley dot com


The graal behavior is a lot more sane:

    graal:
    [info] SoFlow.square_i_two   10000  avgt   10  5338.492 ± 36.624  ns/op   // 2 *\sum i * i
    [info] SoFlow.two_i_         10000  avgt   10  6421.343 ± 34.836  ns/op   // \sum 2 * i * i
    [info] SoFlow.two_square_i   10000  avgt   10  6367.139 ± 34.575  ns/op   // \sum 2 * (i * i)
    regular 1.8:
    [info] SoFlow.square_i_two   10000  avgt   10  6393.422 ± 27.679  ns/op
    [info] SoFlow.two_i_         10000  avgt   10  8870.908 ± 35.715  ns/op
    [info] SoFlow.two_square_i   10000  avgt   10  6221.205 ± 42.408  ns/op
The graal-generated assembly for the first two cases is nearly identical, featuring unrolled repetitions of sequences like

    [info]   0x000000011433ec03: mov    %r8d,%ecx
    [info]   0x000000011433ec06: shl    %ecx               ;*imul {reexecute=0 rethrow=0 return_oop=0}
    [info]                                                 ; - add.SoFlow::test_two_i_@15 (line 41)
    [info]   0x000000011433ec08: imul   %r8d,%ecx          ;*imul {reexecute=0 rethrow=0 return_oop=0}
    [info]                                                 ; - add.SoFlow::test_two_i_@17 (line 41)
    [info]   0x000000011433ec0c: add    %ecx,%r9d          ;*iadd {reexecute=0 rethrow=0 return_oop=0}
    [info]                                                 ; - add.SoFlow::test_two_i_@18 (line 41)
    [info]   0x000000011433ec0f: lea    0x5(%r11),%r8d     ;*iinc {reexecute=0 rethrow=0 return_oop=0}
    [info]                                                 ; - add.SoFlow::test_two_i_@20 (line 40)

while the third case does a single shl at the end.

    [info]   0x000000010e2918bb: imul   %r8d,%r8d          ;*imul {reexecute=0 rethrow=0 return_oop=0}
    [info]                                                 ; - add.SoFlow::test_square_i_two@15 (line 32)
    [info]   0x000000010e2918bf: add    %r8d,%ecx          ;*iadd {reexecute=0 rethrow=0 return_oop=0}
    [info]                                                 ; - add.SoFlow::test_square_i_two@16 (line 32)
    [info]   0x000000010e2918c2: lea    0x3(%r11),%r8d     ;*iinc {reexecute=0 rethrow=0 return_oop=0}
    [info]                                                 ; - add.SoFlow::test_square_i_two@18 (line 31)                                   
Both graal and C2 inline, but as usual the graal output is a lot more comprehensible.


True. In retrospect, trying to make the Scala transducer type look like Haskell and then hacking into working order was didn't do justice to either language. As I sort of note in the text, the attempt to do it this way was at least partially meant to be "amusing."


There's more missing than that, but, in the spirit of early termination, I had to stop somewhere! Specifically to your points: 1. To preempt the faithful: Stateful transducers don't work (for a broad definition of work) in Clojure or Scala either. It's just that there's no tradition of acknowledging state via type in those languages. 2. Early termination is weird. In Clojure it's a property of the accumulated reduction value, i.e. not the transducer, the reducing function or the reducer/collection. I'm not sure yet whether to try modeling this via type or to try sticking it somewhere else. 3. Rich's talk is great. Also, it's been transcribed: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...


See here for points (1) and (2): https://news.ycombinator.com/item?id=8532710


I had 32k files using up 8GB in /usr/local, and the time spent on "2 minutes remaining" was about 45 minutes. In retrospect, I'm happy that I didn't waste any time on special preparations. One thing I learned is that the ⌘L log window blocks progression from restore to the next reboot; I lost about 15 minutes that way.


Sorry, 32k was the result of `ls -lR /usr/local | wc -l` and then typing on a keyboard with a broken 4. To be much more precise, `find /usr/local -type f | wc -l` is 243185, while (including directories and links) `find /usr/local | wc -l` is 274709.


45 minutes, another lost 15 minutes... wow, you're install went fast! Everyone else seems to be having multiple-hours long installs. :)


It was multi-hour altogether, but the lying about two minutes remaining only took 45 minutes.


I'll add that note. People with problems tended have >100k or more files.


See my reply above. A more accurate count on a keyboard with working keys is 243185. I'm starting to wonder whether the /usr/local-related delay is naturally about an hour, but vastly increased - sometimes catastrophically - by having the log window open. Just a theory.


I've gotten messages from people who didn't even know how to open the log viewer until hours into the process, so it's just a highly variable delay depending on individual circumstances.


Ok, I managed to get a van Laarhoven representation in typed Clojure, though it wasn't exactly a smooth experience. http://blog.podsnap.com/vanhole.html


I apologize for my miscommunication and ignorance. First, the bragging was supposed to be on behalf of the Clojure ecosystem rather than myself. Second, while I am aware of the standard lens implementations in Haskell and Scalaz, I didn't see that either dealt nicely with intra-path transformations, and the Scalaz version didn't seem very concise. If there are more examples, or if I'm wrong about these, I would love to learn more. I agree that the interaction with typed Clojure is not ideal, but at least there's an interaction of some sort, albeit possibly a "hack." Googling "van Laarhoven" has led me to a few hours of reading material and to SPJ's talk, so thanks for that...


Could you demonstrate a simple example of the intra-path transformation? I am not sure that I see exactly how it should be implemented, but so long as it isn't a lens law violation I think you can do it in Haskell's lens system at least.


I was thinking of setting ```:c``` in ```{:a {:b "{:c 5}"}}```. More generally, a leaf in the container tree that is not itself a container but can be converted to and from one. I need to play more with http://hackage.haskell.org/package/lens, but I'd certainly appreciate a shortcut to enlightenment...


So there are a few things going on here

    1. Focusing on "the subtree" instead of "the value
       at the subtree"
    2. Working with data types like `{:a {:b {:c 5}}}` is
       somewhat uncommon in Haskell (too little information
       gets projected into the types)
    3. Doing "along the way parsing"
Each of those are fine to do in Haskell and I could work up an example. Perhaps the best domain for this is using the lens-aeson[0] package since your data type is not so different from JSON. Here you can use the _JSON prism to do your "along the way parsing" (the failure mechanism of prisms catches failed parses naturally). You can also focus on whole subtrees naturally (since the JSON Value type is just a sum over subtrees and values all together, so the natural parametricity distinction is lost).

So I'd look at [0] for a wealth of examples in that vein. I'd also look into zipper lenses. They were removed in more recent versions (I think anticipating splitting them out into another package) but they're available in the 3.* series [1].

[0] http://hackage.haskell.org/package/lens-aeson [1] http://hackage.haskell.org/package/lens-3.10.1/docs/Control-...


Yes, lens-aeson looks pretty damn close. I've got a bunch of reading to do.

The existence of zipper lenses catches me by surprise, as I have been frequently directed at a stackoverflow [0] response on the difference between the two...

[0] http://stackoverflow.com/questions/22094971/what-are-the-dif...


I'm the author of the non-accepted answer to that question. For what it's worth, I think cgrand's is weak in describing both zippers and lenses, but ultimately lands on the wrong distinction.


Sorry about "performant," everyone. After years of being mocked as a pedant for avoiding the word (ok, there may have been other reasons), I decided to dip a toe in the descriptivist waters. Maybe it's too soon. I toyed with "fast" in the title, but that could be taken as referring to ease of use. I'll spend the next few hours trying to come up with a better title.


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

Search: