Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 22 14:03
    antoine-levitt opened #537
  • Oct 22 14:00

    antoine-levitt on optim

    small optimization (compare)

  • Oct 22 13:54
    mfherbst commented #425
  • Oct 22 13:52
    antoine-levitt commented #425
  • Oct 18 11:24
    mfherbst closed #283
  • Oct 18 11:24
    mfherbst commented #283
  • Oct 17 16:02

    mfherbst on gh-pages

    build based on 35b7143 (compare)

  • Oct 17 15:40

    mfherbst on v0.4.0

    (compare)

  • Oct 17 15:39
    JuliaTagBot commented #358
  • Oct 17 15:17

    mfherbst on master

    Bump version: 0.3.10 → 0.4.0 (compare)

  • Oct 17 14:14

    mfherbst on gh-pages

    build based on ea60978 (compare)

  • Oct 17 14:04

    mfherbst on kpathsc

    (compare)

  • Oct 17 13:56
    mfherbst labeled #536
  • Oct 17 13:56

    mfherbst on refactor_plot_bandstructure

    (compare)

  • Oct 17 13:56

    mfherbst on master

    Refactor plot_bandstructure int… (compare)

  • Oct 17 13:56
    mfherbst closed #536
  • Oct 16 18:29
    mfherbst edited #536
  • Oct 16 18:29
    mfherbst edited #533
  • Oct 16 18:29
    mfherbst edited #533
  • Oct 16 18:29
    mfherbst edited #533
Michael F. Herbst
@mfherbst
and if I just want to quickly try something quick and dirty
I do not want to spend 30min to look up and satisfy the interface
so without type annotations I don't have to fully do an AbstractArray
I just implement what is needed and I am ready to go
to do it properly in library code of course you should follow the convention
but that's the second step from my point of view
first get it to work, then get it fast and clean ;)
Louis Ponet
@louisponet
Yea, that's the idea but in reality often I get errors at some part of the code because I didn't throw in the thing that the code expected
Michael F. Herbst
@mfherbst
sure but then you just implement that extra bit
eventually you will have the full interface
but on the way you already got at least some stuff to work
I agree that it is two sides of the coin
Louis Ponet
@louisponet
Okay, then I'll follow that idea for other things I may implement :) but personally I still think just having types on the arguments is like a part of documentation on it's own almost
Michael F. Herbst
@mfherbst
I often had it the other way round with strongly object-oriented code that I needed my object to satisfy two interfaces to work with certain codes, but there were conflicts ...
Louis Ponet
@louisponet
but indeed if the argument's name makes clear what is expected that ofcourse also works
I see
well I'd say that's just shit code then ;D
Michael F. Herbst
@mfherbst
Agree, but sometimes you don't have a choice in science
Louis Ponet
@louisponet
true
Michael F. Herbst
@mfherbst
and better you can hack something and get a PhD, rather than rewrite a library for that reason
Louis Ponet
@louisponet
haha agreed
Michael F. Herbst
@mfherbst
actually I think what is most important is that the philosophy of the code agrees with the philosophy of the language
and julia definitely went the route of "only type when needed"
Louis Ponet
@louisponet
But isn't the philosophy of Julia exactly to type as strong as needed but not stronger?
Michael F. Herbst
@mfherbst
just look at the standard library
exactly
and if you only have one version of a function, why add types for dispatch?
(ok that's pushing it to the extreme of course)
Louis Ponet
@louisponet
I mean usually a numerical function will not be happy with Strings right?
Michael F. Herbst
@mfherbst
and?
so it just breaks during compilation
Louis Ponet
@louisponet
so then if I throw in a string and I get an error that the type of my argument is not right, I know
but getting an error from somewhere inside the function body I think have to open an editor find the body and what it's trying to do to know what I'm supposed to throw in
Michael F. Herbst
@mfherbst
again it's a bit the question of what you want.
yes I agree
I mean we check a bit more strongly on the real high-level interfaces (I think)
well on the other hand you have examples to see what is the right way to do stuff and other documentation
Louis Ponet
@louisponet
One example of something like this I actually ran into while doing the spglib was this darned Int32 vs Int64 in the symops for getting the stabilized kmesh
Michael F. Herbst
@mfherbst
my point is: Either you do low-level hacking and then you have to look at the code or you stay on the surface and then you follow examples to see what should be done
Ok what happened?
Louis Ponet
@louisponet
half a day I wasted trying to call it with the Int64's from julia (which is why originally I added the ::AbstractArray{Int32} type in anger)
Michael F. Herbst
@mfherbst
ah but it's C types
Louis Ponet
@louisponet
in the last function inside the spglib.jl
right and I was like, okay now nobody will be fooled again and just get an error that their array doesn't contain Int32's
Michael F. Herbst
@mfherbst
I see
on the other hand I could argue this is not a Julia / DFTK issue, but a C / spglib issue
Louis Ponet
@louisponet
but in line with the philosophy of the code I removed that and just converted it to Int32's when they're not
Michael F. Herbst
@mfherbst
because really it is the interface
Louis Ponet
@louisponet
certainly
Michael F. Herbst
@mfherbst
yes talking to other languages is a point where you need to type-annotate eventually