> If C can have one, why can't Julia?

*The hard truth, and nothing but it:* If Julia is missing a feature, or has 
one that works in a way that's not the way you want, it's because no-one 
has wanted what you want enough to actually implement it.

That's it. There's no "it can't be done" - Julia is Turing complete, so 
"everything" can be done. There's no "it's not allowed" - no-one is 
stopping you from writing your own package, with your own implementation 
that does what you want the way you want it done, putting it in the package 
repository and seeing it take off. Chances are that if you write something 
that it turns out many others want as well, it will be included in the 
default package distribution in the future (or even in base Julia). Or it 
might not take off, but at least be there for your own enjoyment.

But the entire language, with all tooling, packages, etc - everything that 
is Julia - is very much a community-built product. Everything that is 
there, is there because someone at some point said *hey, this is so 
important to me that I'm going to put it at the very top of my priority 
list*. Creating a sprintf function that fulfills your needs might not have 
made it there for anyone yet. If it's that important to you, maybe that's 
your next contribution?

// T

On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:
>
> I might be wrong, but to me Formatting.jl looks next to useless. The 
> "sprintf" functions it provides only accept one parameter. The main 
> function provided is `sprintf1()`, but even the very clumsy 
> `generate_formatter()` function fails at the most basic tasks:
>
> julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
> ERROR: Only one AND undecorated format string is allowed
>  in generate_formatter at 
> /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23
>
>
> I really don't understand why sprintf() is such a big deal. If C can have 
> one, why can't Julia? I understand the argument that you might want to 
> rewrite the implementation later. Fine. Just call the function 
> "__temp_sprintf()" and put it in a package called 
> "FunctionThatWillGoAwayLater". I don't care. I just want to be able to 
> print formatted strings without a ton of needless hassle.
>
>
>
> On Tuesday, 22 September 2015 10:03:52 UTC+2, Tomas Lycken wrote:
>>
>> By the way, you might also note that the Formatting.jl package is written 
>> and maintained by people who are all active contributors to the main 
>> language repo, and very active members of the community. Even if it's 
>> "external" in terms of how you install it, it's by no means external "in 
>> spirit".
>>
>> // T
>>
>> On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken wrote:
>>>
>>> Julia is a young language.
>>>
>>> This comes with a lot of benefits - for example, it's possible to do 
>>> things *right* from the start. We're currently in a phase where there is a 
>>> multitude of possible solutions to every problem that arises, and we 
>>> honestly don't know which solution proves to be the best one. Testing 
>>> various solutions out in packages, outside of the base distribution, where 
>>> they can compete for popularity, and keep building on top of each-other 
>>> until we reach something which we believe not only is adequate, but 
>>> *really* hits the sweet spot. In other words: sure, formatting numeric 
>>> output is fundamental, but it's a problem with a large solution space, and 
>>> we don't want to lock in on one path yet.
>>>
>>> But Julia's young age also means that there are lots of problems that 
>>> aren't really solved yet, or that have solutions proposed but not 
>>> implemented, etc. For the future, there are plans to include some packages 
>>> (which ones have not been decided, or AFAIK really even discussed) in a 
>>> sort-of "base distribution", so they will be installed upon installation of 
>>> Julia, and available with a single `using` statement. But the 
>>> infrastructure for this is not in place yet, and even if it were, there 
>>> would still be lots of reasons not to make a final decision on which 
>>> packages make the cut until we approach a 1.0 release of the language.
>>>
>>> So yeah, it might seem silly to have to install a package just to get 
>>> fine-grained control of numeric output formatting, but, at least for now, 
>>> that's part of what one could call Julia's "Package Deal" ;)
>>>
>>> // T
>>>
>>> On Tuesday, September 22, 2015 at 9:43:05 AM UTC+2, Ferran Mazzanti 
>>> wrote:
>>>>
>>>> Thanks, that seems to work.
>>>> Still it amazes me how Julia, being a language made for numerical 
>>>> calculations, does not natively support a simple mechanism to print/write 
>>>> large bunches of numbers. I've been in the numerical world for 20+ 
>>>> years and I know printing lots of numbers is something you get on a daily
>>>> basis. I know now the formatting package can help on that (thanks :), 
>>>> what I do not like is the idea of having to install every time a new 
>>>> package
>>>> to get added functionality. I understand there are things that have to 
>>>> go to external packages because of its limited or specialized use, but
>>>> come on... printing number os definitely not one of those.
>>>> Just my 2cents :)
>>>>
>>>> On Monday, September 21, 2015 at 10:52:52 AM UTC+2, Michael Hatherly 
>>>> wrote:
>>>>>
>>>>> https://github.com/JuliaLang/Formatting.jl might help.
>>>>>
>>>>> — Mike
>>>>> ​
>>>>> On Monday, 21 September 2015 10:46:31 UTC+2, Ferran Mazzanti wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I could use some help here, because I can't believe I'm not able to 
>>>>>> easily print formatted numbers under Julia in a easy way. What I try to 
>>>>>> do 
>>>>>> is to write a function that, given a vector, prints all its components 
>>>>>> with 
>>>>>> a user-defined format. I was trying something of the form
>>>>>>
>>>>>> function Print_Vec(aux_VEC,form_VEC)
>>>>>>     form_VEC :: ASCIIString
>>>>>>     str_VEC  = "%16.8f"
>>>>>>     for elem_VEC in aux_VEC
>>>>>>         str_VEC += @sprintf(form_VEC,elem_VEC)
>>>>>>     end
>>>>>>     return str_VEC
>>>>>> end
>>>>>>
>>>>>> However, that doesn't work because it looks like the first argument 
>>>>>> in @sprintf must be a explicit string, and not a variable.
>>>>>> Is there anything I can do with that?
>>>>>>
>>>>>> Thanks a lot for your help.
>>>>>>
>>>>>

Reply via email to