On Mon, Apr 14, 2014 at 1:51 AM, Jeff Waller <[email protected]> wrote:
>
>
> On Monday, April 14, 2014 12:41:05 AM UTC-4, Jameson wrote:
>>
>> We know that the extremes of verbosity (e.g. C) and conciseness (e.g.
>> perl) are 'bad'. But why? Because using C generally means writing more
>> code, which takes more time. Whereas Perl is 'bad' because being the
>> human interpreter to read and understand its very symbol dense syntax
>> is slow, so reading Perl is harder than necessary. However, we have
>> that `C` calls this same function `gets` (4 characters), but `perl`
>> calls it `readline` (8 characters)! Therefore, I conclude that
>> conciseness (and thus usability) is not a function of the length of
>> function names (although let's not be extremist), but of language
>> design.
>
>
> I said it before, I'll say it again, I like the discussion! Agreed about
> the design. However, an impression of "overly verbose" due to the use of
> "unnecessarily long" identifiers, can not be 100% disqualified; I'm not not
> saying Julia is, I am saying don't completely dismiss it.
Of course. Discussion is good. As you pointed out, I was not trying
for precision in my verbage, but I think you got my meaning. (I could
also point out that, for partially this reason, julia tries to avoid
being a dot-heavy-language (I forget the exact term, but expressions
like os.path.absdir))
>
>>
>>
>>
>>
>> additional thoughts:
>>
>> I can type readline slightly faster than readln, since the former is a
>> word, and the second is not. But the difference doesn't matter
>> compared to the time it takes me to figure out what to type.
>
>
>
>>
>>
>> default arguments are good, like Stefan said, and should be added to
>> `readline`. however, to me, this qualifies as an improvement in
>> language design, in contrast to shortening the the length of a
>> function name
>>
>
> LoL, so you're saying you're not liking the readln? I also prefer to not
> dwell on 2 characters.
I don't like readln much, but also don't care to dwell on two
characters. (Comment on below: If my golf code "lost" because readline
was two characters longer, I would probably consider that a win. The C
code we were playing with couldn't get much smaller because of the
characters required to encode `while(){}` and `for(;;;){}` in C
couldn't be reduced.)
>
>
>>
>> please don't a function `Base.readln() = chomp(readline())`, it's
>> really unnecessary and confusing. However, I would encourage you to
>> make a function `MyModule.readline() = chomp(Base.readline())`, as
>> convenient.
>>
>
> I don't like the MyModule idea because of this interpretation. You're
> saying "please work around the cumbersomeness of this language by creating a
> workaround yourself." This does go to your language design idea. I'll
> state it
>
> A language should streamline common tasks by default.
>
> if you agree with that, then I would argue that the current default behavior
> of readline() instead streamlines the edge case (read the delimiter) and
> complicates the common case (throw away the delimiter).
>
You can only compose this function in one direction, which is why it
helps for the default function to be the one that doesn't throw away
information. Although, I guess we could have a function
Base.readline_without_chomp, and then use the MyModule approach to
change the local behavior. Since modules were essentially designed for
allowing this sort of behavioral reconfiguration, I don't consider it
a abuse to use it. I really don't use readline enough to care strongly
about how it behaves.
>>
>> I feel this incurs the usual problem with creating benchmarks: they
>> don't reflect the real world.
>>
>> in a real julia program, how many times do you type `readline`? in a
>> well-structured program, it's should probably be true that you have a
>> single entry point into your program from the user, so that you can
>> unit test your helper functions without user intervention. in the
>> julia repl, there are 3 uses of the readline function in 2 files, or
>> 0.15% of the lines in those files.
>
>
> Oh there are other things. But I have to start somewhere, I'm not even sure
> how to rank things yet. But ... you looked through the codebase? That's
> awesome! Does that mean a change would be easy because it affects so little
> in regression?
I used grep and `wc -l`. Not exactly looking, but roughly sufficient.
Interestingly, all three use cases require / expect that the input is
terminated by a newline. Looking at all uses of readline in Base, I
find 3 uses in base that don't care about the newline (they aren't
affected either way) and 4 that require the explicit newline
terminator. Probably this has resulted from the function being defined
in that manner, but it is still reasonably interesting.
>>
>>
>> in a real jQuery program, how many times do you expect to type `$`?
>> every line? several times per line? perhaps just every tenth line, if
>> you really like spacing out your code? `$` is the roughly jQuery
>> equivalent of `using` in julia (or more precisely, `import ... as
>> ...`). since javascript does not natively have strong code separation,
>> e.g. "modules", it is necessary to fake it with some shorthand.
>
>
> I wonder if this is going to come back to bite those that program in
> Javascript on the server side using node.js and the postgres plv8 features.
I haven't followed node/jQuery that much recently, but are people
really using jQuery on the server? I recall there used to be an option
to use a different identifier rather than $, so all hope is not lost.
>>
>>
>> codegolf can be fun anyways. my roommate last year and I spent several
>> months trying to cram a wireless encoding algorithm into a tweet. I
>> think we could only get down to ~186 characters, by which time gcc
>> didn't even want to parse the code (it warned of using a deprecated
>> feature of K&R C, and aborted). clang still computed the correct
>> answer (although I think it also emitted a warning that could not be
>> silenced with any command line flag). the original C was somewhere
>> around three times as long, iirc.
>
>
> So you're saying you spent 2 months on reducing the size of a function. I'm
> guessing you know that alg pretty well now. Did you get frustrated?
> Thinking back, how would Julia stack up? Sounds pretty low level, is that
> even the kind of thing Julia could be used for?
Julia could have done the calculation. It is fairly well suited for
it, since it mostly required a lot of bit twiddling. However, it would
almost certainly have been much longer. We didn't spend much time
overall, but every few days or weeks we would have a thought that
allowed us to cut off 2-10 more characters off, by moving bits of code
around. It made me more familiar with very esoteric precedence rules
in c, such as that the following is perfectly valid:
int c, a[10]; int z = (sizeof(p)-c)[p];
although we were also used various rules of C syntax to skip declaring
our variables
I can't say we were necessarily frustrated, since it was completely
open-ended, just-for-fun, and we got much further than expected (we
initially thought 220 characters, ignoring a #define statement was
about as good as it could get). as mentioned above, the hard limit we
finally reached was needing to write out `while(){}` `for(;;;){}`
(because we needed to have two loops over the data) and `a(*x){}` (to
declare the function call / body)
> I like golf for at least this reason, it's an open format with few rules
> the objective it to stretch a language to it's limits; here's the best it
> can offer! And then you either win or lose at least as far as the
> competition goes, but then afterwards you can understand why.
Exactly! I don't know that you can necessarily use it to compare
languages in a very meaningful way, but it certainly seems like a way
to get a much stronger appreciation for the language and it's parser.
>
> Sometimes it will be; "oh boo, we lost because our IO function has 2 extra
> letters in the identifier" -- ehh no big deal.
>
> But maybe sometimes (which is my hope) it will be oh, our language is
> missing something, and if it had that the program would be greatly
> simplified.
