The Joys Of Programming

RolandofGilead wrote:
trueheart78 wrote:

Thanksgiving sale is on. 'turkey2013' coupon code for 50% off ebooks/screencasts/audio books.

http://pragprog.com/promotions

Someone go buy
http://pragprog.com/book/elixir/prog...
so that I may live vicariously! No time to learn Elixir as I've decided to actually finish my project of adding const to Mono so I'll have something semi-impressive on my github in case I need a job (layoffs are coming soon where I work).

Ended up going back and picking this up, and it really looks to be right up my alley (read chapter 1).

Now, to reading and learning

Elixer looks really interesting. I'm a big fan of Erlang and its VM. But I'm much more likely to use Scala in my job than Erlang.

Anyone else thinking of doing this Coursera course?

Which one?

This one. Duh. The one.

Stupid lack of coffee and sleep. I meant this one. https://www.coursera.org/course/andr...

Edwin wrote:

Stupid lack of coffee and sleep. I meant this one. https://www.coursera.org/course/andr...

I'm currently in https://class.coursera.org/reactive-... and I have barely enough time to watch the videos and look at the assignments.

Same here with https://class.coursera.org/algs4part...

Not enough hours in the day, but I put the Android one on my future watch list. After finding GenyMotion and Android Bootstrap, it's about time for me to port over my Windows Phone app.

I am taking Machine Learning course. I have read the syllabus and started on the first weeks' work. Then things got super crazy in real life and I have not been back to it.

Kind of like all the Coursera courses I have taken so far.

tboon wrote:

Kind of like all the Coursera courses I have taken so far. :(

Yup, same here. Trying again soon with the self-study Compilers course, hope I can stick with it better this time.

I strongly recommend Android Bootstrap; it is a really solid system. Check out RoboGuice (or Dagger) and Android Annotations as well--at first they may appear similar (and they both can do basic injection) but RoboGuice/Dagger make DI a lot simpler and Android Annotations can make your application code a lot cleaner via code generation.

GenyMotion is okay. Better than the default emulator, nowhere near as good as just dumping to a real device.

I stumbled across something kinda cool the other day, *whisper* in Java *whisper*. Only a parody of myself truly hated Java, but now I'm starting to actually like it.
I wound up writing code similar to the following.

public void makeTypeB(final int importantInt) { someCollection.put(new TypeB() { @Override public void interfaceMethodX() { doImportantThing(importantInt); } }); }

The final keyword is required to make it work, does this pattern work for objects too?
edit: And if that inner class isn't compiled such that it has a hidden field, I'll be more impressed.

I too am taking Machine Learning course...and failing miserably at keeping up with it, I've already decided to quit, I'm just going to download the materials and assignments for later.
It does not help that for reasons as yet unknown to me, watching and hearing that guy makes me want to pound nails in my skull, he just talks so slowly and explains everything, maybe I'll try a vid player that can be sped up.

Anonymous inner classes as a crappy closure are a very common idiom (see Android and twelve frigging thousand of them for any UI work). To enclose variables requires a final ref for reasons that are sometimes frustrating though usually smart (it allows them to take make unreseatable guarantees upon what object is actually enclosed), but yes, it works fine with objects too.

Java is my first big OO-y language but I'm kind of digging it. Java +1

My only real issue with Java is that the standard library is built around the idea of constructing and disposing of objects pretty much constantly. It's nigh impossible to avoid GC churn in Java. The language itself is pretty okay though.

Actually, the pain of object creation is less the GC churn than the fact that java objects are super super heavy. There are other languages which do even more allocation in normal use but which hurt less because the things being allocated are smaller and less complicated. (Smaller means more allocations per major GC. Less complicated means there's a cost to having every Object have its own built-in lock and signal variable.)

Still ends up being orders of magnitude less painful than Python, of course.

Ehh, I think both of these posts are kind of overstating it.

As far as object allocation itself goes, I'm not really sure where the (oddly persistent) idea that Java objects are "heavy" comes from so I would really be interested in seeing a source for that--I've worked in perf-conscious Java environments and object creation was never something we considered with regards to performance unless it was in quantities sufficient to jank the GC. j.l.Object is either 8 or 12 bytes - sizeof(ptr) + sizeof(int). A polymorphic C++ object is sizeof(ptr); the overhead isn't huge. I don't see a way you really improve on j.l.Object short of removing the lock/signal var (which I wouldn't want to do)--D objects are, IIRC, also 12 bytes, while objects in Python, JavaScript, etc. have to retain a handle to any methods attached to an object for the duration of their lifetimes. So as far as object weight go I'd say Java does pretty well for itself.

Performance-wise, in the general case (that is, no custom allocators), Java object creation will be faster than (most) heap allocations in C or C++. My understanding is that--and I've studied Hotspot a little but never this specifically, so I may be wrong--that the addition of a lock variable isn't really relevant to object creation because in competent JVMs (which is to say, Dalvik probably does this wrong) object creation is O(1) with regards to space; it's essentially the incrementing of a pointer in the eden free store. (This saves a malloc() and thus a potentially slow search for free memory space, which is why it can be faster than C++.) Also it's worth considering that you've got escape analysis and scalar replacement for some data structures -- i.e., a j.a.Point may never actually even hit the heap if its lifetime and accesses can be proven to be doable in a couple of registers.

Regarding temporaries: given the way that Hotspot handles memory allocations, the temporary objects being created very rarely have time to leave eden and can be reclaimed both quickly and cheaply. Modern GC algorithms are optimized mostly for this and it's just not a big thing unless you're instantiating thousands in a frame or you have consciously mistuned your eden size. You can definitely exacerbate issues by naive use of objects--hello, Scala (though it's worth it)--but it's hard and you have to be trying to do it.

(This isn't an endorsement of Java as a thing. There isn't much redeeming in the language or in the culture around it. But the JVM is awesome.)

As an extreme case, I knew a guy working on a (probably badly designed) server system in Java where the GC cycles took 30 seconds to complete. The backflips they went through to avoid heap allocations were ridiculous. I really like GC in general, but it feels like Java really fights the desire to be GC efficient. And I know there are incremental GCs and other GCs providing soft realtime performance guarantees, which helps things a lot. But you generally have to go to a third party (like IBM's Metronome) to get a really good one.

But, AFAIK, Java doesn't really do anything that everybody else doesn't do regarding objects. I don't think that your criticisms hold truer to Java than to the CLR or to Python or to a JavaScript VM. If you instantiate a StreamWriter atop a Stream it is a staggering thirty-two bytes and a constructor call with something like 3-4 setter calls and as long as it doesn't pass out of scope it gets finalized in eden whenever it matters. These objects are just shy of conceptual in nature and really just Don't Matter except in the utterly extreme case where you should be writing shared-nothing code and sharding your system anyway.

Every JVM shop has a horror-story system in their past, sure. But the cause of it matters more than the fact of its existence. GC pauses like that are generally caused either by configuration mistakes or design failures. Configuring Hotspot does require a relatively deep understanding of it and mis-tuning the heap (via both memory size and collection strategy) is really common. It's common to go "oh, I just set -Xms and -Xmx and I'm good!" and that's wrong; you need to profile your application tweak the knobs with your application's behavior in mind. It's usually better to make the young generation space much larger than HotSpot will default to, for example; a good, competent shop can generally profile an application to see how much data "should be" in the old generation and increase the size of the young generation to better account for this.

I haven't explored G1 enough to really discuss it effectively, but CMS (the standard old-gen GC in Java 6) does not have to cause huge long pauses when it stops the world--it has to stop the world, but it doesn't have to take forever to do it. In my experience that's caused almost entirely by having huge amounts of non-live data in your old generation that must be iterated over; like, lots of shops eschew memcached or other solutions for "just keep HashMaps in memory" and this is just dumb. This isn't a "avoid heap allocation" thing, this is a "be smart about what objects you let persist" thing and it's common to almost every managed environment in some form or another; the problems manifest differently in different environments, obviously, but sticking multiple gigs of lookup data in your process is never not foolish. (Last job regularly rolled out 14GB heaps, of which something like 4GB was lookup tables and boatloads of HashMaps. But we didn't have to tell people to write code in any specific way to get the perf we wanted and we had tuning geniuses on staff; the only times we went into oldgen with regularity were when we had bugs, and each web server in our pool served hundreds of thousands of requests a day.)

Metronome isn't a silver bullet; their implementation of hard RT hurts general-purpose performance when you opt into it and it too has a number of restrictions you must bear in mind that are no more intuitive than HotSpot's. RTSJ, which you really need to be using to get the most out of Metronome, is pretty vile, too--for me it's a big "why bother, I know C++" and I tend to think that poor programmers made tolerable via Java are going to go back to being poor programmers with RTSJ. (Azul's Zing, on the other hand, is interesting. It provides soft RT guarantees, which I don't care about, but it also offers a fully pauseless GC with very respectable performance in the general case and only minor dereferencing penalties after a garbage collection. It is a great choice for the overwhelming majority of perf-sensitive-but-not-misdesigned-for-RT Java stuff out there.)

I don't really like GC in the majority of use cases--I think it moderately improves poor programming practices at the expense of being able to be efficient and smart when you need to be. For code that I have to care about long-term I think manual memory management in the vein of idiomatic, RAII-based C++ greatly improves your conception of what your code is actually doing and supposed to do. But if you're going to have a garbage-collected virtual machine environment, the JVM is close to all there is. Except the Windows implementation of the CLR, which Windows, which nope. (I'm interested in Rust for web development because a GC-optional web development environment with strong typing appeals to me in very funny places.)

I am off to start a new job as a Ruby developer tomorrow. I'm looking forward to that!

I'm not going to weigh in on the C++/Java discussions, but they are the main languages in my previous job, and I'm not sad to be taking a break from them.

This is only nominally about programming, in that (a) programmers often manage documentation and (b) wikis require some generic "programmer" support. That said, if I were to make a recommendation to my small-business employer (~50 employees) as to a wiki platform, are there any that stand out based on your experience? I've tried single-user wiki stuff (TiddlyWiki, for instance) in a past life, and DokuWiki seems simple enough (our enterprise tool is PHP and its architect is our sole and lead developer, and he loves PHP, and I cribbed someone else's Wordpress plugin code and tweaked it and "wrote" a Wordpress plugin one time so I'm basically an advanced developer myself okay). Ease of installation, however, doesn't speak to (a) scaling and (b) ease of use. Any such system will be maintained in the near term (~6 months at least) by me or my "boss" or said PHP pirate ninja, so it needn't be single-click install-for-dummies.

Thanks in advance for any tips.

MikeSands wrote:

I am off to start a new job as a Ruby developer tomorrow. I'm looking forward to that!

I'm not going to weigh in on the C++/Java discussions, but they are the main languages in my previous job, and I'm not sad to be taking a break from them.

How's the first week goin'?

muraii wrote:

This is only nominally about programming, in that (a) programmers often manage documentation and (b) wikis require some generic "programmer" support. That said, if I were to make a recommendation to my small-business employer (~50 employees) as to a wiki platform, are there any that stand out based on your experience? I've tried single-user wiki stuff (TiddlyWiki, for instance) in a past life, and DokuWiki seems simple enough (our enterprise tool is PHP and its architect is our sole and lead developer, and he loves PHP, and I cribbed someone else's Wordpress plugin code and tweaked it and "wrote" a Wordpress plugin one time so I'm basically an advanced developer myself okay). Ease of installation, however, doesn't speak to (a) scaling and (b) ease of use. Any such system will be maintained in the near term (~6 months at least) by me or my "boss" or said PHP pirate ninja, so it needn't be single-click install-for-dummies.

I like DokuWiki if you have a reasonable expectation of everyone involved learning (or already knowing) wiki syntax.

If not, Google Drive.

We used to use the former, and now use the latter because designers simply would not use the wiki.

Google Drive seems like just a network drive full of Word docs. Luckily we're not supporting designers, but accountants and underwriters and sales folks. There is a lot of industry-specific stuff and product-specific stuff that in the 2.5 months I've been here still don't quite make clear sense to me. I assume I'm not the only one, especially as we're about to add ~30 people to the company.

How are you using GD?

My current job is developing features for our wiki farm, which is a large installation of MediaWiki running several hundred individual sites. When I was interviewing for the position a few months ago I was able to quickly setup a basic installation on my linux box without any prior experience using the framework. As the platform that runs Wikipedia, it's pretty much the standard for wikis and you get the bonus of instant familiarity. They're pretty close to completing integrating their experimental WYSIWYG rich-text editor that is currently in use on wikipedia.org, but it's still a bit of a hassle to set up with the current version. That means that unless everyone is comfortable working with wikitext (with the help of a toolbar), your best option is still going to be Google Drive for the time being.

muraii wrote:

Google Drive seems like just a network drive full of Word docs.

It sort of is, except for the fact that it's browsable via the web, and the documents all open and display in-place in your browser, making it not all that dissimilar to browsing a wiki.

And there are some serious advantages, like simultaneous editing. During a conference call, it's common for a number of us to be simultaneously editing a "notes" document, to ensure we get everything down in text. It's extremely nice for that.

Also nice for putting files right alongside documents. Our e-book library is there, and it's a whole lot nicer dragging new books to upload to GDrive than it was attaching them to wiki pages.

During a conference call, it's common for a number of us to be simultaneously editing a "notes" document, to ensure we get everything down in text.

Getting that working well must have taken some virtuoso programming on Google's part.

Malor wrote:
During a conference call, it's common for a number of us to be simultaneously editing a "notes" document, to ensure we get everything down in text.

Getting that working well must have taken some virtuoso programming on Google's part.

MS had that as a feature of OneNote back in the early 2000's via a installed program. I miss OneNote actually. It's one of MS's killer apps or was. I havent used it in a long time.

Malor wrote:
During a conference call, it's common for a number of us to be simultaneously editing a "notes" document, to ensure we get everything down in text.

Getting that working well must have taken some virtuoso programming on Google's part.

Once upon a time they had this really cool project called Google Wave...

psoplayer wrote:
Malor wrote:
During a conference call, it's common for a number of us to be simultaneously editing a "notes" document, to ensure we get everything down in text.

Getting that working well must have taken some virtuoso programming on Google's part.

Once upon a time they had this really cool project called Google Wave...

I will always remember the collaboration with Legion on documents there.