|
idk what storm or scalding are but they sound stupid and pointless.
|
# ? Oct 8, 2013 20:52 |
|
|
# ? May 26, 2024 20:52 |
|
are we still doing this
|
# ? Oct 8, 2013 21:02 |
|
Shaggar posted:idk what storm or scalding are but they sound stupid and pointless. storm is a pseudo-real-time distributed computing system that works with tuple streams. with hadoop you read big blocks of data and process them on a batch basis. storm just sets up consumers and emitters of streams. they can split and combine etc. same distributed concept but trickles of data being processed quickly it's actually really cool. scalding is a scala library that compiles scala code to sequences of hadoop jobs and manages them. it looks really cool but since it's a huge pain in the rear end i can't recommend it. use cascading instead. it does the same job, it's not painful to use w/ scala, and it's mavenized!
|
# ? Oct 8, 2013 21:13 |
|
tbh i have never used hadoop "in anger" i just spent a week in training and it was really fun to hack on the labs.
|
# ? Oct 8, 2013 21:14 |
|
i have done the storm thing "for real" but i'm ashamed of the use case so i'm not gonna talk about it here. suffice to say storm is pretty nifty in my book
|
# ? Oct 8, 2013 21:23 |
|
Notorious b.s.d. posted:i'm ashamed of the use case so i'm not gonna talk about it here. you are safe here, share with us
|
# ? Oct 8, 2013 23:19 |
|
we're still doing this 1. list-flattening behaviour 2. sigils 3. packages and modules 4. context-sensitivity 5. BEGIN blocks and many more
|
# ? Oct 8, 2013 23:28 |
|
perl was one of the first languages i picked up and sigils were never unintuitive, even the whole '@array but $array[0]' thing. it's like conjugating a verb or something. the fact that you can have @var and $var and &var and %var at the same time is a bad idea though
|
# ? Oct 8, 2013 23:37 |
|
Notorious b.s.d. posted:storm and scalding are both way worse than hadoop eh it's not hard to avoid using storm.py, all it does is set up a jvm invocation. which is a good thing because storm will piss itself over just about everything. idk about scalding
|
# ? Oct 8, 2013 23:43 |
i like perl a lot, and c++
|
|
# ? Oct 8, 2013 23:47 |
|
Notorious b.s.d. posted:i have done the storm thing "for real" but i'm ashamed of the use case so i'm not gonna talk about it here. storm is rly cool and i hope i can convince newjob to give it a try. they're using mysql + batch jobs to do work that a message queue + storm topology should have
|
# ? Oct 8, 2013 23:48 |
|
Notorious b.s.d. posted:tbh i have never used hadoop "in anger" i just spent a week in training and it was really fun to hack on the labs. should try cascalog. it's pretty sweet
|
# ? Oct 9, 2013 01:59 |
|
Shaggar posted:so either run each hadoop in its own jvm or run it inside its own container. ez pz problem solved. this is exactly the problem osgi solves, but without the hacks
|
# ? Oct 9, 2013 02:01 |
|
Notorious b.s.d. posted:it's like they just dumped somebody's source tree + readme.md to github and called it done in like 99.9% of cases where you get that feeling, it's accurate and that's exactly what they did so in all likelihood, someone just *DID* dump their source tree and readme.md to github and called it a day
|
# ? Oct 9, 2013 02:07 |
|
alright i'll do ocaml since nobody else is gonna (nice to see GrumpyDoctor's F# post though!) 1. global interpreter/gc lock. you cannot have multiple threads running ocaml code in parallel within a single process. concurrency works fine, since the runtime releases the lock before any syscall that may block. inria developed a parallel ocaml gc a long time ago and abandoned it due to performance impacts on single-threaded code. current efforts to fix the global lock range from new parallel gcs to hybrid solutions that run multiple ocaml runtimes per process and pass messages between them. these are coming together, but none are officially endorsed or supported yet afaik 2. lacking good namespace support. compilation units all live in the same global namespace, so you can't have name collisions at that level. but there are many common module names like "utils", so you have to either use a prefix like "proj_utils" which is no better than C, or package everything up into a single global module named "proj", which interferes with separate compilation. here again there are proposed solutions from the community, but technical disputes remain 3. no automatic instantiation of type classes a la haskell. ocaml modules can do everything type classes can do (in fact records suffice, you don't even need modules), minus the magic of picking the appropriate type class to pass into your function. you have to do that manually. as oleg would put it, the only difference is => vs ->. still, this difference is important enough that type classes have not taken off in the ocaml world 4. error messages could be better in certain cases for newbies. this has improved a lot recently, but type inference can still produce errors that are tricky to understand unless you know how the inference engine works. for example, a type error might point to chars 39-42 on line 16, and say "this expression has type foo, but we expected type bar". if i actually meant for the expression in question to have type bar, then this helps me. but what if foo is correct? then what i want to know is, where'd you get the idea that it should be bar? did another case of the same pattern-match have type bar? did i call a function that expects a bar? what led to the unification failure? 5. jon harrop still posts occasionally on the mailing list
|
# ? Oct 9, 2013 02:39 |
|
for people that don't really like haskell typeclasses, what would you rather have instead?
|
# ? Oct 9, 2013 02:45 |
|
i would read phil wadler's paper "how to make ad hoc polymorphism less ad hoc", and see if what you dislike is actually type classes themselves, or just some peculiarity of haskell's implementation, especially their tendency to choose names like Monad and Histozygomorphism
|
# ? Oct 9, 2013 02:52 |
|
i know there's an article floating around called "scrap your typeclasses" or something and it makes an argument for just using records i think? idk i just skimmed it like a year ago
|
# ? Oct 9, 2013 02:56 |
|
woah this wadler paper is old
|
# ? Oct 9, 2013 03:03 |
|
well from my perspective as an ocaml programmer, one typeclass i'd like to have is Num. in ocaml you cannot add floats with the (+) operator, it has type int -> int -> int. for floats there is a separate operator (+.), and yet another for arbitrary precision numbers. if i had a haskell-style typeclass, i could use just one operator, and the compiler would know how to instantiate it for the type i need. in ocaml the best i can do is explicitly pass the type to the operator, which is not really any better than just using (+.) an alternative solution is to define the arithmetic operators inside each relevant module, so inside module Float i would have (+) = (+.) etc. then i could write Float.(3.14 + 2.71 - 6.9). so-called "delimited overloading" seems to solve the problem in a lot of cases, but i still can't write "type foo with show" without resorting to some camlp4 or at least parsetree-rewriting
|
# ? Oct 9, 2013 03:08 |
|
just use floats for everything. problem solved.
|
# ? Oct 9, 2013 03:45 |
|
MeramJert posted:just use floats for everything. problem solved. hmm, according to the paper you recommended, this is literally what miranda does (did?)
|
# ? Oct 9, 2013 05:34 |
|
Type classes to enable overloading arithmetic operators etc are pretty cool, type classes to enable Text.Printf are hilarious, type classes to enable Monad.Control.Trans.Control or w/e can go gently caress themselves.
|
# ? Oct 9, 2013 06:36 |
|
qntm posted:we're still doing this this list is good specifically because perl newbies will defend sigils to the end sigils seem to make sense at the surface but once you learn how perl works and why the Std lib requires gloves on occasion sigils start to look like a mistake Perl: minutes to learn, a lifetime to weep
|
# ? Oct 9, 2013 07:05 |
|
Nomnom Cookie posted:storm is rly cool and i hope i can convince newjob to give it a try. they're using mysql + batch jobs to do work that a message queue + storm topology should have yeah, moving work from batch jobs to continuous event processing is a biggest win on lovely databases. A trickle of data 24/7 is an easier workload to plan for than a late night batch job that hammers N corner cases for M hours
|
# ? Oct 9, 2013 07:07 |
idk sigils make sense to me although idg why they are necessary
|
|
# ? Oct 9, 2013 07:27 |
|
sigils are bad in perl because they dont share namespaces and you end up with weird stuff like $array[0]
|
# ? Oct 9, 2013 08:48 |
|
OBAMA BIN LinkedIn posted:idk sigils make sense to me although idg why they are necessary 2. add new built-ins without breaking old scripts (in theory lol)
|
# ? Oct 9, 2013 09:32 |
|
Good things about perl: 1. it's not php 2. it's not javascript 3. it's not ruby 4. it's not ksh 5. it's still not php
|
# ? Oct 9, 2013 10:26 |
|
coffeetable posted:playing with the thrust CUDA library right now clock() returns approximate processor time used by the program, not waiting time. And you didn't even count transfer times. Also, my CPUs are faster than your GPU. code:
shrughes fucked around with this message at 15:52 on Oct 9, 2013 |
# ? Oct 9, 2013 10:27 |
Soricidus posted:Good things about perl: Bad things about perl: 1. developers
|
|
# ? Oct 9, 2013 10:51 |
|
1. there is no library or namespace system. there is only include files. 2. the standard library is sparse and undocumented, although at least there is one popular de-facto utility library, which changes core classes. 3. people write language extensions instead of libraries, so you can't compose things easily 4. good luck tracing a method to a class, to a file, to a package. the package names are routinely garbage. 5. the unicode and string handling is hilariously broken. 1. default arguments are built at definition time 2. the baked in threading model is terrible for concurrency 3. strings *almost* behave like lists, implying array like access (untrue), 4. although there is a nod towards immutability and functional composition, these are clunkier than they should be. 5. i'd rather have let than global. (i'd rather have dynamically scoped variables than global singletons in modules, for things like stdin, stdout, et al.)
|
# ? Oct 9, 2013 10:52 |
|
1. there is very little in the way of building modules, but then again most programs are small 2. string handling, io handling, is painful and clunky. 3. nah i can't hate on prolog that much
|
# ? Oct 9, 2013 10:54 |
|
C++: 1. integers can silently overflow 2. pointers and pointer-like things can be null/empty, because it has std::move and rvalue references instead of real linear types 3. defaults to mutable instead of const 4. heinous amounts of syntax for things that should be simple like declaring a reasonably safe abstract class. no algebraic datatypes / pattern matching. 5. almost every library outside the STL is a horrible uninteroperable pile of poo poo
|
# ? Oct 9, 2013 12:04 |
|
shrughes posted:clock() returns approximate processor time used by the program, not waiting time. And you didn't even count transfer times. Also, my CPUs are faster than your GPU. yeah i discovered this a lil later in the book, welp -_-. when i get back to the comp next week ill try it again using device time
|
# ? Oct 9, 2013 12:14 |
are there any good online courses or books for a python beginner?
|
|
# ? Oct 9, 2013 15:03 |
|
A Socialest posted:are there any good online courses or books for a python beginner? codecademy
|
# ? Oct 9, 2013 15:04 |
|
tef posted:1. there is no library or namespace system. there is only include files. what languages are these
|
# ? Oct 9, 2013 17:16 |
|
A Socialest posted:are there any good online courses or books for a python beginner? learn python the hard way
|
# ? Oct 9, 2013 17:27 |
|
|
# ? May 26, 2024 20:52 |
|
also (paging tef) whats a good intro to prolog/logic programming book I wanna write me a logic dsl in haskell like miniKanren or something, that would be cool
|
# ? Oct 9, 2013 17:28 |