Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.6: what has changed since Julia 1.0?

oxinabox.net

Post reply on HN
Print view View original

151–160 of 212 posts

Re: Julia 1.6: what has changed since Julia 1.0?

#151

Post by adgjlsfhk1 »

Certhas wrote: post #134
BadInformatics wrote: post #92

Earlier quoted context omitted.

I'm not sure that's a fair characterization. Core team members have expressed serious interest in getting more static verification, interfaces and other type goodness into the language, but if you try to force the issue it turns into a Python 2->3 problem. Not to mention that there are few if any examples of how to fit type checking alongside multiple dispatch (e.g. C# punts with dynamic). I personally find static ty…

One thing is the Core Team Members and their long term plans, which I'm not privy to. The other is the impression generated by interacting with others in the community online, where people disagree with the very premise that there is a problem. I also see your point that not too much is known in this design space, but I also think that's why it would be good for the community to step up and experiment with this more.…

Note that if you ask on slack, you often will get answers from the core team members. They're pretty open. The main place where plans aren't the most clear is when there are features that everyone knows would be good, but aren't on the top of any of the the main people's to-do list. The JuliaLang repo has over 1000 people who have contributed, so a lot of the time, a new feature is just the result of a community member making a random PR. Stack trace improvements for example, started as a package, got ported to Base, and got improved by a bunch of people contributing to design decisions.

Re: Julia 1.6: what has changed since Julia 1.0?

#152

Post by jampekka »

Sukera wrote: post #145
jampekka wrote: post #111

Earlier quoted context omitted.

I'm not using modules. I usually start with one file with a demo or similarly named function that is called if the file is called as an entry point (like if __name__ == '__main__', except Julia makes it even worse). First the "actual" code is in separate functions in that file. No global state. I tend to refactor code out of there to separate files, and then somehow import it. An ugly way is include, and I've tried R…

I'm using `!isinteractive() && main()` as my `if __name__ == '__main__'` equivalent, not sure how that's even worse? It's not equivalent no - include doesn't introduce a namespace and neither does includet. Compiled stuff from packages (=modules with a Project.toml) is cached between runs, scripts just don't have that luxury of seperation. @from doesn't look into the files you're including and (somewhat simplified) v…

!isinteractive() && main() doesn't probably work for my case. Oftentimes my files may have a main of their own, but that isn't called if the file is just imported. I don't use Julia interactively anyway (I've explained why many times in this thread). (Edit: the equivalent Julia chant is `abspath(PROGRAM_FILE) == @__FILE__,` IMHO slightly even more obtuse than Python's, but this is a minor detail).

If a "package" is used only by me and only from files controlled by me, Project.toml is clearly pointless ceremony. And `]generate MyPkg` too, and assumes REPL on top. Python manages this (albeit with some stupid arbitrary restrictions) fine, Node manages this fine. The compiler doesn't need that stuff for anything.

I didn't look into the implementation of @from, but I picked it up from a huge bikeshedding bug (still open, from 2013...) about local module imports, and assumed it's doing imports instead of including, as it also has a separate namespace. From the code [2] it's not clear to me exactly what it does when, but one branch seems to be generating a module with the code imported on the fly. Not sure this should be any different than any other module for the compiler. Are you sure you're not talking out of your ass on this one?

I don't care if people for some reason want to write their pointless ceremony, but what I don't understand is that people are so jealous of it that they insist of pushing it on everybody else too. I just want to somehow get access to those symbols defined in another file, why does this need more than the path of the file? I'm sure using just files-as-modules would probably be less work for the compiler, and it's easy to have a byzantine package ceremony on top if you want (Python has dozen or so available, so lots to draw from).

[1] https://github.com/JuliaLang/julia/issues/4600 [2] https://github.com/Roger-luo/FromFile.jl/blob/master/src/Fro...

Re: Julia 1.6: what has changed since Julia 1.0?

#153

Post by socialdemocrat »

vanderZwan wrote: post #114
klmadfejno wrote: post #3

> People often complain about the “Time To First Plot” (TTFP) in Julia. I personally have never minded it – by the time I am plotting something, I have done minutes of thinking so 20 seconds of compilation is nothing. This amuses me. I hadn't really considered the author's perspective, and now I think it aligns with my take on it pretty well.

If that's what you're used to it's fine probably, you'll often have no choice but to adjust your workflow to it and make it work. But if you've ever experienced an environment that instantly shows you results and lets you get into a fast iterative loop to explore your data, it can be hard to give that up again. Source: my current and previous job were basically data viz programming jobs which were all about optimizin…

It is literally “first” time, not every time. Thus if your worry is that you cannot do fast iterations in Julia where you plot multiple times, then your worries are misplaced.

Second, third, forth etc plots in Julia are fast. Likely faster than any of the competition as it is running highly optimized native code at that point.

Re: Julia 1.6: what has changed since Julia 1.0?

#154

Post by sgt101 »

aliceryhl wrote: post #113
sgt101 wrote: post #103

Earlier quoted context omitted.

>"strong type checker"???? I like julia because of the super powerful and super strong type checking. Have I misunderstood what is meant by strong type checker?

What do you even mean? It doesn't even catch that an argument's type doesn't match on a function call with types specified. It also can't catch trivial stuff like misspelling a struct field on a variable of known type. If you want to be called a "super strong" type checker, you really have to catch that kind of simple issue at compile-time, _not_ when I run the code.

Ahhhh - you want a statically typed language. That's definitely not Julia, you're probably best off with Java there.

Re: Julia 1.6: what has changed since Julia 1.0?

#155

Post by socialdemocrat »

jampekka wrote: post #90
dnautics wrote: post #43

Earlier quoted context omitted.

> People are just different but every camp thinks They're Right and The Others Are Dumb and Stupid And Dangerous. That's not quite right, I think. People are looking for excuses to not use Julia (r new technology X) because it serves as confirmation bias that their choice of is still good and there is no need to start thinking of their extensive training and investment in blub is sunk.

I've tried it dozens of times. I tried it this week and gave up again after several hours. As a language and technology it's way better than the alternatives, but usability of Julia as a programming language is broken by the ridiculous startup latency. I'm sure it's not even really hard to fix (at least by some caching hacks), but for some reason the Julia community is actively resisting such fixes. And don't give me…

People have different style and preferences. I have programmed for over 30 years and I find that REPL based development in Julia beats anything else I have tried in term of productivity, and I have tried a ton of tools, IDEs and languages.

But sure it may not fit your particular preference or it may be that you have simply not learned to use it effectively. It takes some time to work effectively in a REPL style. It took me some years.

Not every language is suited for REPL development. Julia, LISP and Haskell seem quite well suited.

I don’t have quite the same good experience with Python e.g.

Re: Julia 1.6: what has changed since Julia 1.0?

#156

Post by jampekka »

socialdemocrat wrote: post #155
jampekka wrote: post #90

Earlier quoted context omitted.

I've tried it dozens of times. I tried it this week and gave up again after several hours. As a language and technology it's way better than the alternatives, but usability of Julia as a programming language is broken by the ridiculous startup latency. I'm sure it's not even really hard to fix (at least by some caching hacks), but for some reason the Julia community is actively resisting such fixes. And don't give me…

People have different style and preferences. I have programmed for over 30 years and I find that REPL based development in Julia beats anything else I have tried in term of productivity, and I have tried a ton of tools, IDEs and languages. But sure it may not fit your particular preference or it may be that you have simply not learned to use it effectively. It takes some time to work effectively in a REPL style. It t…

It probably depends also on what you program. If the task is simple enough and doesn't need much revisiting, REPL is probably fine. But OTOH, just writing the code for a simple case and running it isn't too bad either.

How do you persist and document your code with REPL-development? Do you log the commands to some separate file? How do you recreate the REPL state if it crashes or you have to reboot? How do you make sure the REPLs state is what you think it is?

These are (some of) the concrete problems that I see with REPL, and that don't exist for program based workflow. And I think these are fundamentally impossible to solve for REPL, and very important for e.g. reproducibility (and IMHO sanity).

Re: Julia 1.6: what has changed since Julia 1.0?

#157

Post by gugagore »

jampekka wrote: post #147
gugagore wrote: post #143

Earlier quoted context omitted.

What do you prefer as an alternative to a REPL? How do you interact with your programs? What seems broken to me about REPLs is how text-centric they usually are. But I want to be able to easily introspect and play with my programs, and REPLs are one way to do that. Really good debuggers and environments for static languages are "another" way.

I just make programs that have an "entry point" (e.g. main() in C or if __name__ == "__main__" in python) and run them off the shell. Oftentimes with some arguments. This is how I interact with most of my programs, and it works fine for my own ones too. I agree that this is probably not for everybody, i.e. if you're not used to the CLI workflow. And admittedly it would be sometimes nice to have e.g. embedded graphics…

> I mostly do the introspection with print, dir and help straight in the code.

This means you have to change your code in order to debug it. And you have to know what you're debugging before you change your code. This is really, in my opinion, much less than ideal, because you have to iteratively instrument your code while you figure out what is wrong. It's a cycle of You print out the first suspect thing, then that produces 5 potential suspects, and you have to decide which one to print next, or print all of them.

You're absolutely right that it rarely fails you, and so I surely want that facility to be at my finger tips. But getting a text representation of a value is literally 33% of what a REPL is for.

Re: Julia 1.6: what has changed since Julia 1.0?

#158

Post by saiojd »

Sukera wrote: post #98
saiojd wrote: post #71

Earlier quoted context omitted.

I've read a bit on type invalidation and I know it's a hard problem (in fact it's hard for me to even wrap my head around it, lol). Still, it's unfortunate. One thing I would like to know is if the difficulties with invalidation are a symptom of the dynamic semantics, or of the compilation model. Namedtuples are cool, but I'm not sure I understand the tradeoffs between using them and using structs. Can I just replace…

Note that I didn't suggest replacing structs with NamedTuples entirely - only during prototyping, while you're figuring out what you want your struct to look like. Structs most definitely will be faster.

I mean, I could, it's just that its pretty hard to know in advance which structs I will have to modify... Most of the time I only need to do minor edits like add 1 field. By that point I need to recompile anyway if I am to switch to NamedTuples...

Re: Julia 1.6: what has changed since Julia 1.0?

#159

Post by gugagore »

CoolGuySteve wrote: post #66
the__alchemist wrote: post #20

> Plotting, it turns out, is basically a really hard thing for a compiler. It is many, many, small methods, most of which are only called once. And unlike most Julia code, it doesn’t actually benefit all that much from Julia’s JIT. Julia’s JIT is normally specializing code, and running a ton of optimizations. But plotting itself isn’t in the hot-loop – optimizing the code takes longer than running it the few dozen ti…

Yeah, I got fed up with Julia's plotting library and wrote a C++ Qt plot function that forks and plots arrays of doubles. It runs instantly even with millions of points.

Now what if your points aren't IEEE double-precision floating point numbers? What if they are Unix time represented as 64-bit integers, and you'd like to format the tick labels according to your locale?

That kind of composability is what keeps me interested in Julia, so I hope that the community keeps improving the overall UX of the language.

Re: Julia 1.6: what has changed since Julia 1.0?

#160

Post by saiojd »

oxinabox wrote: post #112
Sukera wrote: post #98

Earlier quoted context omitted.

Note that I didn't suggest replacing structs with NamedTuples entirely - only during prototyping, while you're figuring out what you want your struct to look like. Structs most definitely will be faster.

> Structs most definitely will be faster. I am not 100% sure this is true. Structs will definately look cleaner in the code. Not sure they will be faster though.

Do you know what the differences end up being when it comes to compilation? (not a rhetorical question - I'd like to know)
Post reply on HN