"me": regarding purely functional programs, they can exist, but they can't actually "do" anything, since by definition, "doing" means altering some state in the outside world. But reasoning as much as possible in a functional way, and expressing your programs in this way (again as much as possible), turns out to be very effective, because reasoning about a virtually limitless amount of shared state is extraordinarily difficult, especially in a concurrent program.
Your argument about the super creative programmer may be valid when you're talking about a single programmer. Good luck getting that programmer to operate as part of a team, especially if you expect everyone else on the team to behave the same way, *especially* if it is a large team. Even if they create their masterpiece in solitude, they're certain to tire of it later and leave it to someone else to maintain. Luckily we have gofmt, so we can reformat it when the team takes over, and they can effectively cooperate to maintain and improve the code. The maestro will gnash his teeth at this, but they will have more important things to work on by that point. Even the best, most creative architects must operate within bounds - buildings need to be safe; they need to satisfy government regulations; they need to be made using existing materials. Anyway, style has nothing to do with the actual program *content*. We're talking about elements that don't affect the behavior of the program. As has been pointed out, your super-creative programmer can write their own tool (in whatever style or language they want!) to translate programs from gofmt-formatted to their preferred style. Nobody even needs to know! On Thu, Jul 27, 2017 at 3:40 PM me <yout...@z505.com> wrote: > > On Thursday, July 27, 2017 at 3:08:08 PM UTC-6, Jan Mercl wrote: >> >> >> Isn't it strange, that we, programmers, well used to model the problem >> once in term of CPU registers and raw memory, then in a pure functional >> style >> > > I don't know that purely functional actually exists: I have been trying to > crack this problem for ages: what exactly is pure functional? > As soon as a functional program has state (a println/print/puts statement > is the first warning), it is no longer purely functional IMO.. > > But, it's a little off topic for this list... still, some functional > programming techniques exist in all programming languages, so still on > topic to some extent. > > As for comparing programming to driving on the road: Okay but programming > is and extremely creative effort, sort of like writing a novel with > mathematics in it. The argument is that you take away people's creativity, > with tools like GoFmt, in the same way forcing a super creative person to > write a poem a certain way, or forcing someone to use a certain style of > mathematics in a paper (which, could be a good thing depending on the case > - but if it is a really creative looney mathematician, you will want him to > write like a wild stallion, free as can be and let him create his > masterpiece) > > Still I like GoFmt - always provide a contrarian position > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
