| Time |
S |
Nick |
Message |
| 01:46 |
|
|
aditsu joined #sourcefu |
| 09:50 |
|
pdurbin |
prologic and dotplus: I just left some comments on the "add a spec" pull request: https://github.com/pdurbin/addressbookmvc/pull/12 |
| 09:53 |
|
pdurbin |
obviously, we didn't start with a spec. everyone did their own thing. which was fine maybe, but maybe we should get on the same page before we onboard too many more people and implementations |
| 10:42 |
|
pdurbin |
prologic (or anyone): do you have time for a Java vs. Python question about constructors? |
| 10:47 |
|
pdurbin |
In Java I sometimes delete the default constructor and provide a constructor that initializes some fields that I always want to be present: https://github.com/IQSS/dataverse/blob/063f9a72ee8b75e4f19d69463d7604373e697d63/src/main/java/edu/harvard/iq/dataverse/search/FacetLabel.java#L12-L15 shows a constructor with `FacetLabel(String name, Long count)` for example. |
| 10:49 |
|
pdurbin |
This prevents the object from being instantiated with null for those fields. How can I do this in Python? |
| 11:49 |
|
prologic |
pdurbin: trying to answer your question(s) |
| 11:50 |
|
prologic |
So you essentially want read-only fields? |
| 11:50 |
|
pdurbin |
no, I want certain fields to be non null when the object is instatiated |
| 11:50 |
|
prologic |
Oh I see |
| 11:51 |
|
pdurbin |
the Java example accomplishes this |
| 11:51 |
|
prologic |
just initialize them in __init__ ? |
| 11:51 |
|
pdurbin |
well |
| 11:52 |
|
prologic |
I will btw give you the idiomatic Python answer :P |
| 11:52 |
|
pdurbin |
can I have __init__ throw an exception or something if the required fields are not supplied? |
| 11:52 |
|
prologic |
so it may not be like what you’ve experienced with java |
| 11:52 |
|
prologic |
you sure can |
| 11:52 |
|
prologic |
or simply make them arguments with non-default values |
| 11:52 |
|
prologic |
def __init__(self, foo, bar, baz): |
| 11:53 |
|
prologic |
btw; porting anything Java to Python (and vice versa) is generally not a good idea; the semantics nor typing are similar at all |
| 11:54 |
|
prologic |
What are you doing btw? :P |
| 11:54 |
|
prologic |
aside from the “how do I do xyz?" |
| 11:54 |
|
pdurbin |
oh, just messing around with Django: https://github.com/pdurbin/addressbookmvc/commit/f1a6309 |
| 11:54 |
|
pdurbin |
got me thinking about constructors |
| 11:55 |
|
prologic |
ahh |
| 11:56 |
|
pdurbin |
so in Python I can't prevent people (myself) from using a no-argument constructor. or so it sounds |
| 11:57 |
|
prologic |
huh? |
| 11:57 |
|
prologic |
classes only have *one* constructor |
| 11:57 |
|
pdurbin |
prologic: do you understand the Java example? |
| 11:58 |
|
prologic |
kind of :) |
| 11:58 |
|
pdurbin |
heh. ok |
| 11:58 |
|
pdurbin |
I think of this as a feature of Java. |
| 11:58 |
|
prologic |
been a while since I ever did Java (10+ years?) |
| 11:58 |
|
pdurbin |
prevent people from shooting themselves in the foot |
| 11:58 |
|
prologic |
ahh |
| 11:58 |
|
prologic |
you cannot do that really with most dynamic languages |
| 11:59 |
|
prologic |
shooting yourself in the foot is precisely why we on that side of the camp like dynamic languages :) |
| 11:59 |
|
pdurbin |
heh |
| 11:59 |
|
prologic |
they allow us to do sometimes often silly things |
| 12:00 |
|
prologic |
most advocates of dynamic languages prfer the contract be between programmers; not interfaces |
| 12:01 |
|
prologic |
interfaces are merely a “guide” that can often be bent or used in more than one way |
| 12:03 |
|
pdurbin |
yeah. maybe I should try Haskell. I kind of like the idea of the compiler helping you |
| 12:06 |
|
prologic |
heh |
| 12:10 |
|
pdurbin |
I'm also sort of interested in optional typing. Starting very dynamic and adding some types where it helps the most. Clojure seems to support this well with schemas. |
| 12:11 |
|
pdurbin |
huh. I got the impression it was built into the language but maybe this is it: https://github.com/Prismatic/schema |
| 12:11 |
|
prologic |
you should check out the many type checking libraries for Python then |
| 12:13 |
|
pdurbin |
yeah. "Moving from Scala to Clojure, I was horrified and crippled by the lack of declared types. In desperation I cling to Prismatic Schema, which lets me describe parameters and return values, which are optionally enforced: contracts that look like types." ▶ PolyConf 15: Contracts as Types / Jessica Kerr - YouTube - https://www.youtube.com/watch?v=zLyd_Ey1GPM |
| 12:13 |
|
pdurbin |
via Jessica Kerr - Cognicast Episode 082 — Cognitect Blog - http://blog.cognitect.com/cognicast/082 |
| 12:14 |
|
pdurbin |
and here is apparently the paper in which it's argued that people are more productive with types declared in method parameters: The Programming Language Wars - http://dl.acm.org/citation.cfm?id=2661156 |
| 12:15 |
|
pdurbin |
this was mentioned in the podcast anyway. I'll have to check out the paper |
| 12:17 |
|
pdurbin |
sivoais: clojure! :) |
| 12:23 |
|
sivoais |
I believe that Perl5 and Perl6 have been experimenting with the same ideas for a while now |
| 12:23 |
|
sivoais |
Perl6 has gradual typing |
| 12:24 |
|
sivoais |
and Perl5 has been using types for validation and documentation, but usually through libraries like Type::Tiny |
| 12:24 |
|
pdurbin |
cool, you can download that paper from http://web.cs.unlv.edu/stefika/Papers.php |
| 12:24 |
|
sivoais |
where the types can end up compiling to C code ;-) |
| 12:25 |
|
pdurbin |
sivoais: yes, "gradual typing". thank you |
| 12:31 |
|
sivoais |
I'm reading this paper and I'm reminded of this post I saw yesterday <http://www.johndcook.com/blog/2015/07/31/the-success-of-oop/> |
| 12:32 |
|
sivoais |
not a long post, just an observation really |
| 12:32 |
|
sivoais |
"plenty of computer science theories that haven?t been tested. For instance, functional programming, object-oriented programming, and formal methods are all thought to improve programmer productivity, program quality, or both" - pg. 7 |
| 12:35 |
|
sivoais |
this is a great paper! |
| 12:35 |
|
sivoais |
asking the right questions :-P |
| 12:37 |
|
sivoais |
reminds me of the work being down under the "Psychology of Programming Interest Group" <http://www.ppig.org/> |
| 12:41 |
|
pdurbin |
I printed it out at least. Not sure when I'll have time to read it. |
| 12:43 |
|
sivoais |
I just finished :-P |
| 12:45 |
|
|
Azgarech joined #sourcefu |
| 12:45 |
|
Azgarech |
Hello all |
| 12:45 |
|
sivoais |
hi! |
| 13:07 |
|
pdurbin |
Azgarech: welcome! |
| 13:07 |
|
pdurbin |
sivoais: my kids are too loud. can't read |
| 13:08 |
|
pdurbin |
sivoais: did it explain anything about types in method signatures? |
| 13:14 |
|
sivoais |
pdurbin: yeah, on pg. 10 (pg. 292 on paper). It cites a handful of studies. |
| 13:16 |
|
sivoais |
I have a feeling that most of the benefit of types in that context is because it clearly documents the contracts like discussed before |
| 13:16 |
|
sivoais |
which means that tools like code completion can use that information |
| 13:17 |
|
sivoais |
I've wanted to take a look at how code completion in languages like Python work without running any code |
| 13:24 |
|
prologic |
sivoais, yeah I agree with that |
| 13:24 |
|
prologic |
however a counter point is that this is useful only for IDE(s) |
| 13:24 |
|
prologic |
and developers that develop the "UNIX" srtyle I guess don't rely on this as much (if at all) |
| 13:28 |
|
sivoais |
yep, I'd be one of those :-P I often have the docs popped open in another terminal window as I code and seeing what kind of parameters are expected helps me even if they are duck types |
| 13:29 |
|
sivoais |
that's only if I'm unfamiliar with a library. Which is probably just a week or 2. After that, the names of parameters are enough :-P |
| 13:31 |
|
prologic |
same |
| 13:32 |
|
prologic |
So by that token I find the whole argument of types to provide useful information to IDE9S) kind of silly |
| 13:32 |
|
prologic |
what it really does is give you compile time restrictions on your program |
| 13:33 |
|
prologic |
inevitably making "some" things harder to do |
| 13:33 |
|
prologic |
like anything dynamic :) |
| 13:34 |
|
pdurbin |
sivoais: thanks! yes, I think the claim made in the podcast about what parts of static typing is most beneficial (use in method signatures) is probably supported by one of those references in that paper |
| 13:35 |
|
pdurbin |
sivoais: all this discussion is pretty early in that podcast if you'd like to listen |
| 13:37 |
|
sivoais |
I'll give it a listen! I'm trying to diagnose why my phone won't charge properly right now, but I've downloaded it for later :-) |
| 13:40 |
|
pdurbin |
cool. there's some great scala vs. clojure discussion in there |
| 13:41 |
|
pdurbin |
prologic: when I only wrote little scripts I used vim. Now I use an IDE and I really like it. Call me lazy. I think it makes me more productive. I still use vim every day though! :) |
| 13:41 |
|
prologic |
yeah |
| 13:41 |
|
prologic |
we're all different and work more effectively in different ways |
| 13:42 |
|
prologic |
I find things like auto completion get in the way mself |
| 13:42 |
|
prologic |
and I don't need an IDE to look things up for me that I can look up myself more quickly using tools like grin/grind |
| 13:42 |
|
prologic |
but that's just me! |
| 13:42 |
|
prologic |
call me a UNIX pureist :P |
| 13:42 |
|
prologic |
purist* |
| 13:51 |
|
|
aditsu joined #sourcefu |
| 13:54 |
|
pdurbin |
prologic: don't get me wrong. I love Unix. what's grin/grind? |
| 13:56 |
|
prologic |
https://pypi.python.org/pypi/grin |
| 13:56 |
|
prologic |
basically grep/find on steroids :) |
| 14:01 |
|
pdurbin |
right, right, I use ack for this. fairly often even on projects where I use an IDE |
| 14:02 |
|
pdurbin |
I'm very much a minimalist at heart so I completely understand not using an IDE. In Java, however, not using an IDE is slowing yourself down, probably. |
| 14:03 |
|
pdurbin |
For Python I'm still trying to decide if I should set up vim better or use PyCharm. Or some other IDE. |
| 14:04 |
|
pdurbin |
I have a strong preference for gratis tools so I may not go for PyCharm. |
| 14:14 |
|
Azgarech |
I may had it to viperr |
| 14:14 |
|
pdurbin |
Azgarech: add it? |
| 14:15 |
|
Azgarech |
yes in the tools featured in Viperr |
| 14:15 |
|
Azgarech |
just put it in directly on the distrib ISO |
| 14:16 |
|
pdurbin |
Azgarech: add what? |
| 14:16 |
|
Azgarech |
grin |
| 14:16 |
|
Azgarech |
sorry |
| 14:17 |
|
pdurbin |
ah. ok. cool |
| 14:18 |
|
pdurbin |
Azgarech: prologic made a Linux distribution: http://vallinux.org |
| 14:21 |
|
pdurbin |
prologic: Azgarech made a Linux distribution: https://viperr.org |
| 14:21 |
|
pdurbin |
:) |
| 14:21 |
|
Azgarech |
a minimal Linux |
| 14:21 |
|
Azgarech |
I like the idea |
| 14:45 |
|
dotplus |
pdurbin: I forget, do you Vim? If so, a) Ack support for vim https://github.com/mileszs/ack.vim b) All sorts of python goodness for vim https://github.com/klen/python-mode |
| 14:46 |
|
dotplus |
They're still both on my list of one day tools to look into, but I'm hopeful they'll be good. I can only justify a certain proportion of my time to explore/improve tooling; sometimes I actually have to use the tooling. |
| 14:47 |
|
dotplus |
I already use ack a fair bit. |
| 14:47 |
|
pdurbin |
dotplus: yeah, I'm a vim person. thanks |
| 14:50 |
|
Azgarech |
:) |
| 16:37 |
|
sivoais |
I contributed to ack.vim, but turns out that I prefer git-grep since it is faster |
| 16:40 |
|
pdurbin |
interesting |
| 16:44 |
|
sivoais |
and if you're just searching for symbols, ctags is nice |
| 16:45 |
|
pdurbin |
yeah, I should probably get better set up with vim in general |
| 17:48 |
|
sivoais |
pdurbin: listening to the podcast... |
| 17:50 |
|
sivoais |
there's some points where I'm hearing something and wondering why they don't just make their tools work better together rather than trying to duplicate an idea for each tool |
| 17:51 |
|
sivoais |
I don't know Clojure, but why do they have docstrings, schema, and test generators that all contain the same idea? I would put it in one place and generate it in the other places |
| 17:52 |
|
sivoais |
Keep it DRY |
| 17:52 |
|
sivoais |
Obviously there are times when it is just one-off and too much work to try to figure out the right abstraction. |
| 17:54 |
|
sivoais |
I'm specifically thinking about how they talk about the JS 53-bit numbers example |
| 18:58 |
|
pdurbin |
sivoais: that schema thing she mentioned is not built in: http://irclog.greptilian.com/sourcefu/2015-08-01#i_131017 |
| 19:04 |
|
sivoais |
oh, I understand that! But if I make an extension to the language, I'm going to try my hardest to make sure it works with other parts of the language and other extensions in a clean way. |
| 19:06 |
|
sivoais |
e.g., see <https://metacpan.org/release/Type-Tiny>. It is a type constraint library for Perl5. The docs include information on how to make it work with various OO frameworks. |
| 19:07 |
|
sivoais |
and then that library ends up being used by <https://metacpan.org/pod/Kavorka> which changes much of the Perl5 syntax |
| 19:09 |
|
sivoais |
only slightly related... have you ever seen object mapper libraries for Java? |
| 19:12 |
|
sivoais |
like: <http://dozer.sourceforge.net/>, <http://orika-mapper.github.io/orika-docs/> |
| 19:30 |
|
pdurbin |
I haven't. |
| 19:33 |
|
pdurbin |
and I might need to relisten about the JS number example |
| 19:36 |
|
pdurbin |
I finished the language wars paper. Still thinking about it. |
| 19:40 |
|
pdurbin |
They're definitely taking the long view. |
| 19:52 |
|
pdurbin |
And they're right, of course. |
| 19:54 |
|
pdurbin |
The language wars are a problem. But how big of a problem is it? |
| 20:24 |
|
sivoais |
Exactly what was on my mind. I'm not averse to working in a polyglot environment. And with a good compat layer (perhaps like Dozer), you can make it possible to get the different components to talk to each other. |
| 20:25 |
|
sivoais |
As long as you can bind the code easily and put a sane interface around it, it's not that hard to deal with. |
| 20:25 |
|
sivoais |
I did read this yesterday: <http://250bpm.com/blog:42> |
| 20:26 |
|
pdurbin |
I mean, duplication of effort is expensive but it's survial of the fittest on some level. |
| 20:26 |
|
pdurbin |
"Are you a programmer-mathematician or a programmer-handyman?" |
| 20:28 |
|
sivoais |
perhaps the idea of the complexity involved in our tools is related to how we percieve the number of languages and libraries that we deal with |
| 20:29 |
|
sivoais |
how much of that duplication of effort is core algorithms rather than business logic? |
| 20:30 |
|
pdurbin |
The web example is almost a bit comical. Yes, perhaps PHP, Javascript, SQL, HTML, CSS, and JSON are used. How realistic is it to replace all this with a single language? This is why I say they take the long view (which is healthy). |
| 20:31 |
|
pdurbin |
I feel like I'm being too negative. It's a good paper. Good for people to think about. I went ahead and shared it at http://or8.net/pipermail/codecraft/2015-August/000031.html |
| 20:32 |
|
pdurbin |
first post of August! :) |
| 20:32 |
|
sivoais |
\o/ |
| 20:33 |
|
pdurbin |
I'm sort of reminded of Spaceballs: "Why are you always preparing? Just go!" |
| 20:33 |
|
pdurbin |
that's how the web was made :) |
| 20:33 |
|
sivoais |
hahah |
| 20:34 |
|
sivoais |
;-) like "Worse Is Better" |
| 20:36 |
|
sivoais |
With WebAssembly, things might change :-P |
| 20:38 |
|
pdurbin |
yeah, will be keeping an eye on that. or an ear. I listened to http://cppcast.com/2015/07/jf-bastien/ which was good. before that I thought wasm was already out |
| 20:39 |
|
pdurbin |
dotplus: that reminds me. I finally merged in your spec into https://github.com/pdurbin/addressbookmvc :) |
| 20:39 |
|
pdurbin |
dotplus: thank you very much! |
| 20:52 |
|
sivoais |
I don't understand why the WebAssembly design includes designing an AST |
| 20:52 |
|
sivoais |
<https://github.com/WebAssembly/design/blob/master/AstSemantics.md> |
| 20:52 |
|
sivoais |
The name *assembly* would seem to imply that it is just an instruction set |
| 20:57 |
|
sivoais |
My guess is that this AST form is meant to be compiled and optimised further. It's just an intermediate representation. Not a bytecode. |
