Julia Computing raises $24M Series A • Hacker News Board

Re: Julia Computing raises $24M Series A

#241

Post by StefanKarpinski » Thu, Jul 22, 2021, 5:04 PM UTC

enriquto wrote: post #237

StefanKarpinski wrote: post #235

Earlier quoted context omitted.

This is an important point: abstractions like generic functions are only as good as how much people respect them, and enforcement of that is largely cultural. You can add technological levels of enforcement, but those are limited at best because people are brilliantly devious and can find ways to break any technological enforcement if they set their minds to it; the key to preventing that is convincing them to set th…

> We would never dream of using bitshift operators to do I/O Or the sum operator for string concatenation, which is the epitome of non-commutative operation. I like your point of view, but still I'm skeptical of function and especially operator overloading. Shouldn't these semantic constraints that you mention be enforced by the language? For example, the language does not let you overload + for a non-commutative ope…

Technical enforcement would be nice, but it's a hard design problem and my point is that even with that, you still need the cultural aspect. Time and time again, we see that culture trumps technology for these kinds of things. In this case, the proof is in the pudding: in Julia there is no technical enforcement of consistency, but semantic meaning of generic functions is broadly respected and generic code works. It would be nice to add some kind of protocols that support enforcement, but it's (apparently) not necessary and it's a hard design problem.

> For example, the language does not let you overload + for a non-commutative operation

It does allow it? I'm not even sure how one would disallow non-commutative operations. How would you know if a definition is commutative?

Re: Julia Computing raises $24M Series A

#242

Post by StefanKarpinski » Thu, Jul 22, 2021, 5:08 PM UTC

enriquto wrote: post #239

dmytro__p wrote: post #238

Earlier quoted context omitted.

I was curious what Julia decided to use for string concatenation (+ method would be the least surprising option for me since it's common for the most of source code in use, even while the string concatenation is non commutative). I was surprised to find Julia uses the multiplication method for string concatenation. For me it feels as wrong as using bitshift operators for I/O but maybe I'm missing something.

+ is terribly wrong for string concatenation and people who used it first were illiterate freaks. If I had to chose among my many reasons to avoid python this by far is the strongest one. I'm forced to use formatting operators and string interpolation just to avoid the stupid + Multiplication for concatenation makes perfect sense: it is commutative, associative, and consistent with mathematical notation. A space woul…

We considered juxtaposition with string literals for concatenation for a while, as in `file ".txt"`. That would make `a "" b` a natural string concatenation syntax, which rather like it, but Jeff felt it was a bit too clever/weird, so we didn't do it.

Re: Julia Computing raises $24M Series A

#243

Post by enriquto » Thu, Jul 22, 2021, 9:43 PM UTC

StefanKarpinski wrote: post #241

enriquto wrote: post #237

Earlier quoted context omitted.

> We would never dream of using bitshift operators to do I/O Or the sum operator for string concatenation, which is the epitome of non-commutative operation. I like your point of view, but still I'm skeptical of function and especially operator overloading. Shouldn't these semantic constraints that you mention be enforced by the language? For example, the language does not let you overload + for a non-commutative ope…

Technical enforcement would be nice, but it's a hard design problem and my point is that even with that, you still need the cultural aspect. Time and time again, we see that culture trumps technology for these kinds of things. In this case, the proof is in the pudding: in Julia there is no technical enforcement of consistency, but semantic meaning of generic functions is broadly respected and generic code works. It w…

(Now I realize that you are one of the designers of Julia, I feel deeply honored by your answers. I really love your job with the language!)

> how one would disallow non-commutative operations. How would you know if a definition is commutative?

I don't think that this is possible without solving the halting problem. But in practice, you can do that by documenting this enforcement and making it unfeasible to overload a commutative operator with non-commutative code. For example, the callers of the overloaded commutative operator can and do assume commutativity to optimize compilation; as in, you fill a matrix with "f(i+j)" and it may only evaluate the upper-half of the matrix (this is even more interesting for the associative case). I think that Mathematica does a similar thing, I recall several symbols for operators to be overloaded assuming certain symmetries. As another example, in C++ you must overload "Also, related to Mathematica, using juxtaposition for product is very natural to mathematicians. It is indeed hard point of friction when moving from Mathematica to Maple or Matlab.

Re: Julia Computing raises $24M Series A

#244

Post by DNF2 » Fri, Jul 23, 2021, 1:50 PM UTC

awaythrowact wrote: post #220

cbkeller wrote: post #216

Earlier quoted context omitted.

In Julia it will just dispatch to the correct function. In other words, one package would define `fit(mymodel::TensorFlowModel)` and the other would define `fit(mymodel:PyTorchModel)`, and then when you call `fit` it'll just dispatch to the appropriate one depending on the type of `mymodel`. This dispatch-oriented style also allows a shocking degree of composability, e.g. [1], where a lot of packages will just work t…

I very frequently run into namespace collisions like that. I think they are quite common in large codebases. I am aware of the ability to do eg "import TensorFlow; model = TensorFlow.model; TensorFlow.fit(model,data)" As I mentioned previously, I find Python's OOP "model.fit" syntax to be better, for a variety of reasons. Thank you for your engagement. Have a nice day.

There's some serious misunderstanding here. You do not have to disambiguate the function call, only the construction of the object. You would write

  m1 = TensorFlow.model()
  fit(m1, data)
  m2 = Pytorch.model()
  fit(m2, data)

Julia knows which version of model you are using.

YensorFlow.fit and Pytorch.fit are just different methods of the same function.

You've formed some strong opinions based on a pretty big misunderstanding.

Re: Julia Computing raises $24M Series A

#245

Post by dklend122 » Fri, Jul 23, 2021, 6:21 PM UTC

awaythrowact wrote: post #232

amkkma wrote: post #231

Earlier quoted context omitted.

Thanks so much for taking the time to outline your thoughts...I share the same goals and input from industry experience like this very valuable. This has spawned some discussion on the Julia slack about how best to target your usecase. Can I trouble you to make a post either on discourse or on the slack? I'd really like this to get in front of the broader julia community and core devs, and you're the best person to d…

Always happy to help. Especially the last day or so - I've been waiting on some long training loops so it's been a pleasant diversion. To be 100% honest with you, there's pretty much 0% chance of me adopting Julia in the next 12 months. I evaluated it before embarking on my current project, but ended up going with Python, and now I have several thousand lines of Python code that work fine, and I'm not going to rewrit…

That makes sense, thanks ! Good luck to you as well.

Re: Julia Computing raises $24M Series A

#246

Post by cbkeller » Fri, Jul 23, 2021, 7:27 PM UTC

StefanKarpinski wrote: post #242

enriquto wrote: post #239

Earlier quoted context omitted.

+ is terribly wrong for string concatenation and people who used it first were illiterate freaks. If I had to chose among my many reasons to avoid python this by far is the strongest one. I'm forced to use formatting operators and string interpolation just to avoid the stupid + Multiplication for concatenation makes perfect sense: it is commutative, associative, and consistent with mathematical notation. A space woul…

We considered juxtaposition with string literals for concatenation for a while, as in `file ".txt"`. That would make `a "" b` a natural string concatenation syntax, which rather like it, but Jeff felt it was a bit too clever/weird, so we didn't do it.

Oh interesting. That would work too, but `*` is really quite nice in the context that string concatenation is properly the associative binary operation of a free monoid.