Julia is built around multiple dispatch - when making a call, the method to execute is chosen based on the run-time types of all of the arguments.
Once this choice has been made, Julia compiles the method, specialised for the exact types of the arguments.
So, the dispatch process and the JIT compiler are linked - both are reliant on type information every time a function is called.
This specialisation is the only way the Julia JIT uses runtime type information. Unlike JavaScript JITs, Julia does not track things like the types of local variables during execution (although it may do some static inference). Therefore type annotations for local variables can improve performance.
Mostly spot on, although it's very rare for local variables to require type annotation—type inference can easily figure it out for locals. Unless, of course, they are assigned from an untyped external source the compiler couldn't possibly know. You could, for example read something from a JSON source knowing that it should be an number, annotate it with `json["field"]::Float64` and then the compiler will emit code to check the type and throw an error unless the type is actually a Float64.
You actually don't need explicit types in function parameters unless you're trying to control dispatching. Otherwise the compiler will auto-specialize on call. This blog post might be a better explanation on when it's necessary: https://www.stochasticlifestyle.com/type-dispatch-design-pos...
Some professors have “hard money” jobs where the university covers most/all of their salary; startup packages that are meant to help you get a grant are pretty common, as are fellowships or TAships for students.
However, I don’t think most universities cover much of the actual research expenses.
As for the patent, most places offer a split with the inventor, and may not patent everything; they have a right of first refusal though.
> I am sure method_missing could be implemented in python using various tricks but nobody, afaik, is doing that.
You could probably implement method_missing in Python using either __getattribute__ or __getattr__.
I think this is a small example of why nobody is doing so. It’s not just culture - Python’s object model is so complex that it would be hard to get right.
> why don't people just write clear, explicit, maintainable code instead of trying to be clever
But that’s boring. Seriously, it always amazes me how many programmers allow their decisions to be guided by what’s best for their personal enjoyment rather than what’s best for the project.
> It’s not just culture - Python’s object model is so complex that it would be hard to get right
Exactly! Python is flexible too... using module import hooks and AST transformations you can even implement common-lisp-style-macros... but the language and model is so darn messy and special-case-y that it would blow up in your face if you tried to use it in a real world project :|
Whereas in Ruby you can whip up a nice clean DSL in no time, and people can actually understand how it's implemented and read it's source without being gurus. Whereas the number of Python programmers who properly understand metaclasses and AST wrangling and other stuff you'd need to do DSL-like stuff and have it work correctly can be counted on not that many fingers...
> how would you showcase an experimental feature to the community?
How do other languages do it? Python has the PEP process for discussing design on paper, but I don’t know how they handle experimental implementations.
Genuinely curious, what makes Python look more like pseudocode? The use of colons?
Regardless, I’ve always thought that Ruby is more like pseudocode because with Ruby, I’m able to worry less about syntax and more about what I’m trying to do. Maybe it’s just me?
> Genuinely curious, what makes Python look more like pseudocode? The use of colons?
I used to think it was significant indentation, but if you look at the pseudocode on e.g. Wikipedia, there is no significant preference for either whitespace or begin/end.
Therefore, it’s probably things like `if value in my_map` vs `if my_map.contains(value)` and `[x * 2 for x in my_list]` vs `my_list.map(x -> x * 2)`.
- `if value in my_map` is a one off special case - ugly, nasty, hard to figure out how to extend it (what if I invented my_map to have special logic for `in` ...I need to search the docs for a magic method called for that operator ...if I even know for what keywords to search, ugh)
- `if my_map.contains(value)` is nice and consistent, easy to search for the code of the .contains method and figure out what it does
- `[x * 2 for x in my_list]` another ugly special case syntax, instead of general purpose higher order functions, even in Python while a `.map` method could've been easily added to dictionaries too, we had to wait years (decades?) for dictionary comprehensions to land in the language, and it's another damn special syntax one has to remember. ugh! - a sane solution not involving higher order functions usage would've been to make everything in the language an expression and have `for ...` expressions return lists or dictionaries or sets, still better than the fugly "list comprehension", I really can't comprehend why people like them
- `my_list.map(x -> x * 2)` nice, clean, and general. If I work with a weirder list like thingy and want to see the logic of mapping, I can easily jump to the definition of it's `.map` method
Most pseudocode is ugly and ambiguous and actually hard to read without special context from the text around it because you're never sure what something actually means, can't easily "jump to its implementation code and read it". Same like natural language, hard to non-ambiguously understand and ugly as hell in technical context where math and diagrams work 1000x times better.
I can't understand why people who are trained in math, physics and/or other sciences would ever choose something just because it "looks more like pseudocode"... To me pseudocode rhymes with... pseudoscience! It's never what you want when you can choose something better.
List comprehension in python it’s absolutely hideous.
It’s reversed and you have to define first the function and after where it is applied.
The code completion it’s completely broken in that way since it has no idea on which elements you are operating.
And also are you saying that “list.include? 2” doesn’t look more like English than “2 in list”?
Just as someone who got on the Ruby bandwagon back in the mid 00's there was definitely a feel of Ruby being a "Japanese import language" and at the time for myself, comparing Matz and van Rossom the latter felt like a little bit more of a scientist/engineer than the former who seemed very humanity focused.
Also I think the mantra of "developer happiness is the #1 goal of ruby" kind of makes ruby seem a bit more fanciful and flowery than python.
These are just my personal anecdotes, though, I am assuming that most people (myself included) start eyeing seemingly superficial things like the attitude of the language author when a lot of other qualities of the language are similar.
It’s your point of view. From my point of view ruby looks much more like pseudo code than python. It reads almost like English. And the closures syntax is way better and much more powerful given that it’s not sillily limited to one expression.
On the closure front, you are assuming that `lambda` is the only way of writing a closure in Python. That is not true. You can write a named function (`def blah():`) in the same place, pass it around (within that scope the name is now `blah`), and it will still have access to the variables in the original scope. So it is a closure, just a named one.
At first I rebelled against not having unnamed closures, but then you hit the first problem in a complex case, and the backtrace having sane names suddenly makes it all more than worth it.
Once this choice has been made, Julia compiles the method, specialised for the exact types of the arguments.
So, the dispatch process and the JIT compiler are linked - both are reliant on type information every time a function is called.
This specialisation is the only way the Julia JIT uses runtime type information. Unlike JavaScript JITs, Julia does not track things like the types of local variables during execution (although it may do some static inference). Therefore type annotations for local variables can improve performance.