HN user

joegaudet

619 karma

Co-Founder and Engineer 0 at Matygo.

http://www.joegaudet.com http://www.matygo.com http://hackernewsers.com/users/joegaudet.html

Posts14
Comments128
View on HN
[dead] 6 years ago

So.... how about taking sketches and turning them into photos?

If you're doing something like play in scala you usually need the program running in the Intellij context, but it can also hook up to the debugging port of a JVM or to the PHP interpreter running inside of a VM.

IntelliJ is a pretty complete suite of a tools, a pleasure to use (has VIM mode too :P)

IntelliJ has great debugging integration with JS / PHP / Scala (the tools I use currently).

Set a breakpoint in the code, refresh the browser, and all the variables in the scope will be annotated with their value at break time.

This is really what you're after when you're println debugging - it has the advantage of showing you everything in a minimally intrusive way which is helpful when you don't know what you're looking for exactly.

[dead] 11 years ago

I'm not entirely sure this belongs here, as it's not entirely 'interesting' but I suppose it does have the word database in it.

Really hard not to break Godwin's law here...

Really great read, I recently lost a friend who was among many other great things Jewish. As a "Gentile" I found the entire Shiva process both historically / anthropologically interesting and very helpful with the mourning process.

My thoughts go out to her and her family.

Fair Warning, I worked with the other for some time, and have been having an out of band convo with him.

One of the things I absolutely HATE about scala is operator overloading - and the excessive abuse of it. I ran into it just now using some library that used ==.

A Case:

List(1,2) == List(1,2); true Array(1,2) == Array(1,2); false

The reason for this is obvious, list implements equals and does a deep compare. While Array.equals is a pointer compare (like how java do).

This would be obvious in Java because that would look like.

ArrayList<> a = ArrayList<Int>(); ArrayList<> b = ArrayList<Int>(); a.equals(b); // equal because it's a value compare

versus

int[] a = new int[5] int[] b = new int[5] a == b; // obviously false because it's a reference compare.

The lack of a universal idea about what == means is pretty dangerous IMO.

*edited for spelling

The main issue at the end of the day is compile time. They are working hard to address this, and from the first day we started using Scala to now, it's improved dramatically - but definitely lots of room for improvement where that's concerned.

For sure you can, but the internals of the libraries can also cause NPEs because of turtles all the way down :P

We've been running scala in production for 4 years, and had our share of NPEs in our code and in the libraries we host. My point I guess was just that it's not entirely true that they will not boil to the surface on occasion.

Having jumped back into some green field work in Scala in the past few days, I will say I'm quite impressed with the improvements to the SBT, IntelliJ, universe. Compile time seems to be improved considerably (though the project is still quite small so time will certainly tell).

One problem, which is also one of the advantages of scala is that the interop with Java often means that all your Option[] etc code can still get NPEed by some offending Java Lib you've decided to use.

As the fidelity and ubiquity of pure scala libs improves this will hopefully go away to a some extend.

I've seen this a bunch of places, until it's done real time with arbitrary images + content, I don't really see the value.

Would be cool if we could do it for translucent toolbar etc.