Re: Linus' idea of "good taste" code

[Kagamin via Digitalmars-d]

On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:
It is not worth it, the web is dying.  I was stunned to see 
this chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928


They just spend increasingly more time in twitter when not at 
home.

Re: Linus' idea of "good taste" code

[Patrick Schluter via Digitalmars-d]

On Thursday, 3 November 2016 at 06:11:08 UTC, Joakim wrote:
On Sunday, 30 October 2016 at 10:04:02 UTC, Patrick Schluter 
wrote:

On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:


It is not worth it, the web is dying.  I was stunned to see 
this chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the 
web numbers in those places are much worse. Combined with 
mobile passing even TV for time spent, there is no point in 
wasting time porting D to a dying platform.


Yes, because outside of web on mobile nothing else exists... 
bwahahahah


Pretty soon it won't:

https://mobile.twitter.com/asymco/status/793401867053195264



Even that chart shows a flattening to an asymptote not a linear 
trend. This means desktop will maube go a little bit down but it 
won't disappear. What people often forget is that professional 
office PC will never be completely replaced by mobile. What also 
happens in that branch (i.e. in office environment) is still a 
continuation to replace PC application by browser applications. 
This means that still focussing on good web solutions server or 
client side is a good investment in any case.



On Sunday, 30 October 2016 at 16:35:54 UTC, Laeeth Isharc wrote:
And wouldn't the changes to runtime and phobos be quite 
similar for both dmd and ldc? I don't see how the work flow 
would be any different as a language user whether you used an 
LDC with wasm back end,  or dmd with similar.


The changes to druntime and phobos wouldn't depend on the 
compiler used, but it is difficult to test unless you have a 
compiler with working codegen, so that usually comes first.  
You can go ahead and make changes to druntime- not much has to 
be done for phobos, as the idea is to encapsulate 
platform-specific code in druntime, though a minority of phobos 
does call platform-specific APIs- based on the spec or 
available headers, but you won't know if it will work well till 
you can run it.


Joakim - native on mobile is so much better (setting aside 
having to deal with Apple or Google)   but I guess the browser 
isn't going away on the desktop for a while yet.


I'm actually a heavy web user, have been for almost a 
quarter-century (though I don't use webapps, mostly reading), 
which is why that chart was so surprising to me.  While native 
mobile apps are usually more responsive, they are not ideal for 
reading, as I'm not going to install and load up The Verge's 
app, or an app for every other news site, every time.


The problem for the desktop browser is that the desktop is 
going away, as the linked tweet above shows.


No it is not. Linear extrapolation of an incomplete chart is 
almost always erroneous.


I went from using a FreeBSD desktop and a dumbphone five years 
ago to an Android smartphone and two Android tablets today, ie 
no desktop or laptop since my ultrabook died late last year.  
In my household, we went from using two smartphones, two PC 
laptops, and a Mac laptop four years ago to three smartphones, 
three Android tablets, and a Mac laptop today.


This is a shift that is happening in most households, as a PC 
overserves most and a mobile device will do.  Many D users are 
power users who cling to old tech like the desktop and the web, 
so they are missing this massive wave going on right now.  I 
myself missed the death of the mobile web, as I'm such a heavy 
user.


still bwahahaha, web technology will stay a bit longer, panicking 
is a bit premature yet.

Re: Linus' idea of "good taste" code

[Joakim via Digitalmars-d]

On Sunday, 30 October 2016 at 10:04:02 UTC, Patrick Schluter 
wrote:

On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:


It is not worth it, the web is dying.  I was stunned to see 
this chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the 
web numbers in those places are much worse. Combined with 
mobile passing even TV for time spent, there is no point in 
wasting time porting D to a dying platform.


Yes, because outside of web on mobile nothing else exists... 
bwahahahah


Pretty soon it won't:

https://mobile.twitter.com/asymco/status/793401867053195264

On Sunday, 30 October 2016 at 16:35:54 UTC, Laeeth Isharc wrote:
And wouldn't the changes to runtime and phobos be quite similar 
for both dmd and ldc? I don't see how the work flow would be 
any different as a language user whether you used an LDC with 
wasm back end,  or dmd with similar.


The changes to druntime and phobos wouldn't depend on the 
compiler used, but it is difficult to test unless you have a 
compiler with working codegen, so that usually comes first.  You 
can go ahead and make changes to druntime- not much has to be 
done for phobos, as the idea is to encapsulate platform-specific 
code in druntime, though a minority of phobos does call 
platform-specific APIs- based on the spec or available headers, 
but you won't know if it will work well till you can run it.


Joakim - native on mobile is so much better (setting aside 
having to deal with Apple or Google)   but I guess the browser 
isn't going away on the desktop for a while yet.


I'm actually a heavy web user, have been for almost a 
quarter-century (though I don't use webapps, mostly reading), 
which is why that chart was so surprising to me.  While native 
mobile apps are usually more responsive, they are not ideal for 
reading, as I'm not going to install and load up The Verge's app, 
or an app for every other news site, every time.


The problem for the desktop browser is that the desktop is going 
away, as the linked tweet above shows.  I went from using a 
FreeBSD desktop and a dumbphone five years ago to an Android 
smartphone and two Android tablets today, ie no desktop or laptop 
since my ultrabook died late last year.  In my household, we went 
from using two smartphones, two PC laptops, and a Mac laptop four 
years ago to three smartphones, three Android tablets, and a Mac 
laptop today.


This is a shift that is happening in most households, as a PC 
overserves most and a mobile device will do.  Many D users are 
power users who cling to old tech like the desktop and the web, 
so they are missing this massive wave going on right now.  I 
myself missed the death of the mobile web, as I'm such a heavy 
user.

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On Tuesday, 1 November 2016 at 06:04:41 UTC, Laeeth Isharc wrote:

On Monday, 31 October 2016 at 09:52:55 UTC, Dicebot wrote:

On 10/30/2016 06:35 PM, Laeeth Isharc wrote:

But what I meant was LLVM will have a wasm backend.


Yes, but it is developed so slowly and conservatively, that 
coming up with own proof-of-concept backend may be a chance to 
win early interest. They may speed up greatly though when 
WebAssembly design gets closer to MVP stage, but I am checking 
that regularly.


I was disappointed that after early hype it all went quiet for 
now.


Actually, they have moved one with browser previews and dedicated 
web site jsut as we were talking: http://webassembly.org


I am curious how much attention it will gather on i.e. reddit

But right now it is mostly irrelevant because runtime 
requirements have not been defined in WebAssembly at all, only 
low level byte code stuff. It is all in very early stages 
really.


You have looked into it more than me at a low level, but how is 
it possible then to run an app today in nightly browser in wasm?


How it works right now is that you can use WebAssembly byte-code 
to write a JavaScript-exposed function to be called from plain 
JavaScript. See http://webassembly.org/docs/js . Thus most of 
runtime level stuff is actually done by JS.


There are further plans to expose browser GC inside WebAssembly, 
allow direct usage of browser API like DOM and generally make 
possible to use it with no JavaScript at all - but those are all 
out of scope of MVP milestone.


Taking a step back,  it's quite amusing how much ingenuity goes 
into having to avoid writing Javascript...


Judging by focus points in public statements one can reason that 
actually main driving goal of WebAssembly developers is not to 
throw away JavaScript but to make existing JavaScript/asm.js code 
more efficient (by pre-compiling it on server and distributing in 
binary form).


At the same time such initiative is of great value to company 
like Google who has lost "better JS" competition (remember Dart 
language?) to Microsoft TypeScript. Having common ground in form 
of byte code supported by all browsers will in some way reset the 
competition again.

Re: Linus' idea of "good taste" code

[Laeeth Isharc via Digitalmars-d]

On Monday, 31 October 2016 at 09:52:55 UTC, Dicebot wrote:

On 10/30/2016 06:35 PM, Laeeth Isharc wrote:

But what I meant was LLVM will have a wasm backend.


Yes, but it is developed so slowly and conservatively, that 
coming up with own proof-of-concept backend may be a chance to 
win early interest. They may speed up greatly though when 
WebAssembly design gets closer to MVP stage, but I am checking 
that regularly.


I was disappointed that after early hype it all went quiet for 
now.


I guess there is a window to grab attention,  but language like 
nim already has a JS backend (so they say - I haven't used), and 
I think D is in a different space from languages where how it 
plays on hacker news is most important.   Because if you have a 
wasm backend today for dmd,  I guess it will be some time before 
it's fast,  stable,  and has the basic stuff already in 
emscripten (though maybe with Remedy work it gets easier to wrap 
that).  So given limited manpower maybe the easier job 
(presumably most work needs to be done on phobos and runtime?) 
makes sense because in this case it's also likely the long term 
sensible way.   It would be great if we had a dmd back end early 
of course,  and I would certainly use it as soon as it was stable 
enough.


But right now it is mostly irrelevant because runtime 
requirements have not been defined in WebAssembly at all, only 
low level byte code stuff. It is all in very early stages 
really.


You have looked into it more than me at a low level, but how is 
it possible then to run an app today in nightly browser in wasm?  
 Is it like saying you don't need glibc,  but it's probably a 
better idea to use one written for your platform rather than have 
some combination of assembly and hacked up library designed for 
another architecture and platform (which is what I guess 
emscripten do)?


Taking a step back,  it's quite amusing how much ingenuity goes 
into having to avoid writing Javascript...

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/30/2016 06:35 PM, Laeeth Isharc wrote:
> But what I meant was LLVM will have a wasm backend.

Yes, but it is developed so slowly and conservatively, that coming up
with own proof-of-concept backend may be a chance to win early interest.
They may speed up greatly though when WebAssembly design gets closer to
MVP stage, but I am checking that regularly.

> So on basis of my
> limited understanding,  it would be some work to make LDC produce wasm
> code,  and then runtime and phobos would need work.

Most likely you would need a quite different runtime as most system/libc
level stuff will not be available in browser sandbox but the very same
browser APIs will need to be exposed instead. Most likely whatever
emscripten does for C should be fairly adaptable even outside of LLVM stack.

But right now it is mostly irrelevant because runtime requirements have
not been defined in WebAssembly at all, only low level byte code stuff.
It is all in very early stages really.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/30/2016 07:53 AM, Walter Bright wrote:
> On 10/29/2016 10:30 PM, Dicebot wrote:
>> At the same time intended wasm spec
>> (https://github.com/WebAssembly/design) is
>> much more simple than machine code for something like x86_64. If
>> Walter gets
>> interested, that may be a feasible path :)
> 
> I looked at it for 5 minutes :-) and it looks like typical intermediate
> code that a compiler might generate. It wouldn't be hard to translate
> the intermediate code generated for the dmd back end to wasm. What I
> didn't see was any mention symbolic debug information, linking, or how
> to connect to system services like mutexes, I/O, etc. Time risks would
> also be wasm is an incomplete, moving target.

Well, "risk" and "opportunity" are pretty much synonymous in such
context :) Whoever comes first with easy to use toolchain for new
platform gets all the hype - it pretty much boils down to making
decision if one believes new platform is likely to succeed.

For now I am just keeping my track on relevant information to see where
does it all go.

> Looks like a fun project, but I don't see how I could split off time to
> work on it.

No argument here, it would be premature to pay much attention to it
anyway. I will probably remind you of this topic some time next year
with more information available so that more weighted judgment can be made.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Laeeth Isharc via Digitalmars-d]

On Sunday, 30 October 2016 at 05:30:04 UTC, Dicebot wrote:
On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc 
wrote:

Any thoughts on how much work is involved to port the runtime?
 And what other changes might be involved? The chap that used 
the C backend for LLVM wrote a little mini runtime but I guess 
didn't have to worry about the version blocks in the compiler 
front end as much.   (don't recall what architecture he 
pretended to be compiling to).


Glibc has obviously already been ported to run in browser by 
emscripten.


I have actually meant something quite different - implementing 
new backend for DMD which emits wasm directly (possibly by 
embedding binaryen). That is more work than simply using LLVM 
stack as-is but would result in unique marketing advantage - 
existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is 
rather annoying. And native wasm backend for LLVM is in 
development for quite a while now with no clear ETA.


At the same time intended wasm spec 
(https://github.com/WebAssembly/design) is much more simple 
than machine code for something like x86_64. If Walter gets 
interested, that may be a feasible path :)


Existing pipeline is string together with gaffer tape and string, 
 so it's hardly there yet - and add up that,  last I looked,  
when you turned on O2 with emscripten it didn't always go well.


But what I meant was LLVM will have a wasm backend.   So on basis 
of my limited understanding,  it would be some work to make LDC 
produce wasm code,  and then runtime and phobos would need work.  
 Adam Ruppe of course had something like this working with plain 
javascript and dmd about four years back, including basic D 
wrapping of DOM etc and extern(js).  But compiler has diverged a 
bit from that version used,  and I guess at time there wasn't the 
interest or manpower to turn that experiment /prototype into 
something one could depend on.   But maybe someone would pick it 
up now more people start to be involved,  given that Walter has 
higher priority things to do.


And wouldn't the changes to runtime and phobos be quite similar 
for both dmd and ldc? I don't see how the work flow would be any 
different as a language user whether you used an LDC with wasm 
back end,  or dmd with similar.


Joakim - native on mobile is so much better (setting aside having 
to deal with Apple or Google)   but I guess the browser isn't 
going away on the desktop for a while yet.

Re: Linus' idea of "good taste" code

[Patrick Schluter via Digitalmars-d]

On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:


It is not worth it, the web is dying.  I was stunned to see 
this chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the 
web numbers in those places are much worse. Combined with 
mobile passing even TV for time spent, there is no point in 
wasting time porting D to a dying platform.


Yes, because outside of web on mobile nothing else exists... 
bwahahahah

Re: Linus' idea of "good taste" code

[Joakim via Digitalmars-d]

On Sunday, 30 October 2016 at 05:53:09 UTC, Walter Bright wrote:

On 10/29/2016 10:30 PM, Dicebot wrote:
At the same time intended wasm spec 
(https://github.com/WebAssembly/design) is
much more simple than machine code for something like x86_64. 
If Walter gets

interested, that may be a feasible path :)


I looked at it for 5 minutes :-) and it looks like typical 
intermediate code that a compiler might generate. It wouldn't 
be hard to translate the intermediate code generated for the 
dmd back end to wasm. What I didn't see was any mention 
symbolic debug information, linking, or how to connect to 
system services like mutexes, I/O, etc. Time risks would also 
be wasm is an incomplete, moving target.


Looks like a fun project, but I don't see how I could split off 
time to work on it.


It is not worth it, the web is dying.  I was stunned to see this 
chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the web 
numbers in those places are much worse. Combined with mobile 
passing even TV for time spent, there is no point in wasting time 
porting D to a dying platform.

Re: Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

On 10/29/2016 10:30 PM, Dicebot wrote:

At the same time intended wasm spec (https://github.com/WebAssembly/design) is
much more simple than machine code for something like x86_64. If Walter gets
interested, that may be a feasible path :)


I looked at it for 5 minutes :-) and it looks like typical intermediate code 
that a compiler might generate. It wouldn't be hard to translate the 
intermediate code generated for the dmd back end to wasm. What I didn't see was 
any mention symbolic debug information, linking, or how to connect to system 
services like mutexes, I/O, etc. Time risks would also be wasm is an incomplete, 
moving target.


Looks like a fun project, but I don't see how I could split off time to work on 
it.

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc wrote:
Any thoughts on how much work is involved to port the runtime?  
And what other changes might be involved? The chap that used 
the C backend for LLVM wrote a little mini runtime but I guess 
didn't have to worry about the version blocks in the compiler 
front end as much.   (don't recall what architecture he 
pretended to be compiling to).


Glibc has obviously already been ported to run in browser by 
emscripten.


I have actually meant something quite different - implementing 
new backend for DMD which emits wasm directly (possibly by 
embedding binaryen). That is more work than simply using LLVM 
stack as-is but would result in unique marketing advantage - 
existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is 
rather annoying. And native wasm backend for LLVM is in 
development for quite a while now with no clear ETA.


At the same time intended wasm spec 
(https://github.com/WebAssembly/design) is much more simple than 
machine code for something like x86_64. If Walter gets 
interested, that may be a feasible path :)

Re: Linus' idea of "good taste" code

[Laeeth Isharc via Digitalmars-d]

On Thursday, 27 October 2016 at 16:14:03 UTC, Dicebot wrote:

On 10/27/2016 07:12 PM, Laeeth Isharc wrote:

On Thursday, 27 October 2016 at 16:01:26 UTC, Chris wrote:
On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M 
Davis wrote:
On Thursday, October 27, 2016 15:42:53 Chris via 
Digitalmars-d wrote:

Not easy to be smart with Javascript ;)


Sure, it is. Avoid it. ;)

- Jonathan M Davis


I wish I could! I wish we had DScript for browsers!


I am hoping that when asm.js is more mature,  then we can use 
the llvm back end to write at least part of front end in D.   
Would need runtime ported of course.


I consider native compiler from D to WebAssembly to be one of 
possible unique breakthrough points for D in coming years.


I asked Kai at dconf about what would be involved in porting to 
wasm,  but I think he misheard me,  as his answer was just 
generically about what was involved in porting to a new platform.


Any thoughts on how much work is involved to port the runtime?  
And what other changes might be involved? The chap that used the 
C backend for LLVM wrote a little mini runtime but I guess didn't 
have to worry about the version blocks in the compiler front end 
as much.   (don't recall what architecture he pretended to be 
compiling to).


Glibc has obviously already been ported to run in browser by 
emscripten.

Re: Linus' idea of "good taste" code

[Era Scarecrow via Digitalmars-d]

On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
Eliminating loops is something D adds, and goes even further to 
making code a straight line.


 A problem for myself and probably many programmers, is some of 
the tricks like what Linus did simply doesn't come to mind 
because it's not something we'd seen before so we can't model 
after it, and also that you sort of follow the same logic of how 
you'd resolve it because that's how you were taught to resolve it 
or it's how you know to resolve it.


 Often when I go for code I start with commenting the 
steps/breakdown, then I write each section, refactoring and 
cleaning up and shortening naturally are last, but once code is 
working it doesn't usually change too much even if there can be 
improvement.


 Hmm what we really need is something like a good 100 examples of 
good 'tasty' code, good code in a variety of code, something 
digestible and even explained down for those not following the 
full logic if how/why it works, perhaps even bad examples to work 
up from.

Re: Linus' idea of "good taste" code

[Chris via Digitalmars-d]

On Thursday, 27 October 2016 at 16:14:03 UTC, Dicebot wrote:

On 10/27/2016 07:12 PM, Laeeth Isharc wrote:

On Thursday, 27 October 2016 at 16:01:26 UTC, Chris wrote:
On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M 
Davis wrote:
On Thursday, October 27, 2016 15:42:53 Chris via 
Digitalmars-d wrote:

Not easy to be smart with Javascript ;)


Sure, it is. Avoid it. ;)

- Jonathan M Davis


I wish I could! I wish we had DScript for browsers!


I am hoping that when asm.js is more mature,  then we can use 
the llvm back end to write at least part of front end in D.   
Would need runtime ported of course.


I consider native compiler from D to WebAssembly to be one of 
possible unique breakthrough points for D in coming years.


Can't wait for this to happen!

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/27/2016 07:12 PM, Laeeth Isharc wrote:
> On Thursday, 27 October 2016 at 16:01:26 UTC, Chris wrote:
>> On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M Davis wrote:
>>> On Thursday, October 27, 2016 15:42:53 Chris via Digitalmars-d wrote:
 Not easy to be smart with Javascript ;)
>>>
>>> Sure, it is. Avoid it. ;)
>>>
>>> - Jonathan M Davis
>>
>> I wish I could! I wish we had DScript for browsers!
> 
> I am hoping that when asm.js is more mature,  then we can use the llvm
> back end to write at least part of front end in D.   Would need runtime
> ported of course.

I consider native compiler from D to WebAssembly to be one of possible
unique breakthrough points for D in coming years.




signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Laeeth Isharc via Digitalmars-d]

On Thursday, 27 October 2016 at 16:01:26 UTC, Chris wrote:
On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M Davis 
wrote:
On Thursday, October 27, 2016 15:42:53 Chris via Digitalmars-d 
wrote:

Not easy to be smart with Javascript ;)


Sure, it is. Avoid it. ;)

- Jonathan M Davis


I wish I could! I wish we had DScript for browsers!


I am hoping that when asm.js is more mature,  then we can use the 
llvm back end to write at least part of front end in D.   Would 
need runtime ported of course.

Re: Linus' idea of "good taste" code

[Chris via Digitalmars-d]

On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M Davis 
wrote:
On Thursday, October 27, 2016 15:42:53 Chris via Digitalmars-d 
wrote:

Not easy to be smart with Javascript ;)


Sure, it is. Avoid it. ;)

- Jonathan M Davis


I wish I could! I wish we had DScript for browsers!

Re: Linus' idea of "good taste" code

[Jonathan M Davis via Digitalmars-d]

On Thursday, October 27, 2016 15:42:53 Chris via Digitalmars-d wrote:
> Not easy to be smart with Javascript ;)

Sure, it is. Avoid it. ;)

- Jonathan M Davis

Re: Linus' idea of "good taste" code

[Kagamin via Digitalmars-d]

On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if 
conditionals where possible:


https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e


Dunno, I wouldn't expect an edge case to fall into the common 
flow of the code.

Re: Linus' idea of "good taste" code

[Chris via Digitalmars-d]

On Thursday, 27 October 2016 at 14:54:59 UTC, Idan Arye wrote:


I'd like to point to Joel Spolsky excellent article "Five 
Worlds" - http://www.joelonsoftware.com/articles/FiveWorlds.html


TL;DR: Joel Spolsky argues that different types("worlds") of 
developments require different qualities and different 
priorities, both from the code and the process. Because of 
that, advice given by experts of one world does not necessary 
apply to other worlds, even if the expert is really smart and 
experienced and even if the advice was learned with great pain.


Linus Torvald is undoubtedly smart and experienced, but he 
belongs to the world of low-level kernels and filesystems code. 
Just because such code would be considered "tasteless" there 
doesn't mean it's tasteless everywhere.


Not easy to be smart with Javascript ;)

Re: Linus' idea of "good taste" code

[Idan Arye via Digitalmars-d]

On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if 
conditionals where possible:


https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

This is something we could all do better at. Making code a 
straight path makes it easier to reason about and test.


Eliminating loops is something D adds, and goes even further to 
making code a straight line.


One thing I've been trying to do lately when working with DMD 
is to separate code that gathers information from code that 
performs an action. (The former can then be made pure.) My code 
traditionally has it all interleaved together.


I'd like to point to Joel Spolsky excellent article "Five Worlds" 
- http://www.joelonsoftware.com/articles/FiveWorlds.html


TL;DR: Joel Spolsky argues that different types("worlds") of 
developments require different qualities and different 
priorities, both from the code and the process. Because of that, 
advice given by experts of one world does not necessary apply to 
other worlds, even if the expert is really smart and experienced 
and even if the advice was learned with great pain.


Linus Torvald is undoubtedly smart and experienced, but he 
belongs to the world of low-level kernels and filesystems code. 
Just because such code would be considered "tasteless" there 
doesn't mean it's tasteless everywhere.

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/27/2016 11:24 AM, qznc wrote:
> I'm unsure about Linus' version. For this example, I agree that it is
> elegant. It is fine in this specific case, because everything is local
> within a single function. In general, the trick to use a pointer to the
> element probably not a good idea.
> 
> The article/Linus does not explain the tradeoffs properly, which makes
> it dangerous advice.

I'd agree for some general language but considering it is Linus, C can
be reasonably assumed. And in C land it doesn't even count as "trick",
heavy nested pointer usage is widespread and even somewhat idiomatic -
being comfortable with such code can be expected from any non-newbie C
programmer.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Chris via Digitalmars-d]

On Thursday, 27 October 2016 at 08:24:54 UTC, qznc wrote:

On Wednesday, 26 October 2016 at 09:54:31 UTC, Dicebot wrote:

On 10/26/2016 12:53 AM, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if 
conditionals where possible:


https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e


I find it both funny and saddening how many reddit 
commentators complained about Linus version of that code is 
over-complicated.


"Prefer clear code over smart code" principle is good in 
general but sometimes it is over-applied to the point where 
incompetence gets glorified. And this sucks.


I'm unsure about Linus' version. For this example, I agree that 
it is elegant. It is fine in this specific case, because 
everything is local within a single function. In general, the 
trick to use a pointer to the element probably not a good idea.


The article/Linus does not explain the tradeoffs properly, 
which makes it dangerous advice.


It's like everything in life, like playing an instrument for 
example - or indeed life itself. Nothing, not even the best 
advice, can replace experience - which comes with age. It's only 
when you have a lot of experience that you understand the advice 
given to you by your elders. Then you pass on the same advice - 
but the inexperienced have to make the same old mistakes all over 
again until they understand. Some never do, though.

Re: Linus' idea of "good taste" code

[qznc via Digitalmars-d]

On Wednesday, 26 October 2016 at 09:54:31 UTC, Dicebot wrote:

On 10/26/2016 12:53 AM, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if 
conditionals where possible:


https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e


I find it both funny and saddening how many reddit commentators 
complained about Linus version of that code is over-complicated.


"Prefer clear code over smart code" principle is good in 
general but sometimes it is over-applied to the point where 
incompetence gets glorified. And this sucks.


I'm unsure about Linus' version. For this example, I agree that 
it is elegant. It is fine in this specific case, because 
everything is local within a single function. In general, the 
trick to use a pointer to the element probably not a good idea.


The article/Linus does not explain the tradeoffs properly, which 
makes it dangerous advice.

Re: Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

On 10/26/2016 4:21 PM, sarn wrote:

I like using D's nested functions for simplifying code in the same kind of way.
Sometimes a tiny helper function can make a big difference.


I've also found that nested functions can nicely fix spaghetti code.

Re: Linus' idea of "good taste" code

[sarn via Digitalmars-d]

On Wednesday, 26 October 2016 at 10:48:34 UTC, Marco Leise wrote:
On a more controversial note, I sometimes replace nested blocks 
of conditionals and loops with flat spaghetti code and goto 
with verbose labels. There are situations where you can explain 
straight forward what needs to be done first, second and last, 
but special cases and loops make it hard to tell from "normal" 
code.


Speaking of Linus, that's idiomatic in the Linux kernel for error 
handling.


I like using D's nested functions for simplifying code in the 
same kind of way.  Sometimes a tiny helper function can make a 
big difference.

Re: Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

On 10/26/2016 6:20 AM, Adam D. Ruppe wrote:

I find the most elegant bug fixes tend to be the ones with an overall reduction
of code.

Though, sometimes things are rotten to the core and that net change of -10 lines
comes from a +330, -340 diff


Elegant fixes tend to mean a refactoring is included!

And it's not a hard and fast rule. It's just a red flag.

Re: Linus' idea of "good taste" code

[Nick Sabalausky via Digitalmars-d]

On 10/26/2016 06:42 AM, Walter Bright wrote:


Reminds me of:

1. newbie - follows the rules because he's told to
2. master - follows the rules because he understands them
3. guru - breaks the rules because he understands that they don't apply


I always liked that principle. Tao Te Ching, if I'm not mistaken (though 
I might be).

Re: Linus' idea of "good taste" code

[Mark via Digitalmars-d]

On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if 
conditionals where possible:


https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e



What would you say is the best way to write his "Initialize grid 
edges" code in D? Ideally, I would like something like this:


void initEdges(int val, ref int[GRID_SIZE][GRID_SIZE] grid) {
	map!(a => val)(chain(grid.row(0), grid.row($-1), grid.column(0), 
grid.column($-1));

}

but multidimensional arrays don't have built-in primitives like 
that (as far as I know).

Re: Linus' idea of "good taste" code

[Mark via Digitalmars-d]

On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if 
conditionals where possible:


https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

This is something we could all do better at. Making code a 
straight path makes it easier to reason about and test.


Eliminating loops is something D adds, and goes even further to 
making code a straight line.


One thing I've been trying to do lately when working with DMD 
is to separate code that gathers information from code that 
performs an action. (The former can then be made pure.) My code 
traditionally has it all interleaved together.


Personally, a large amount of control flow statements (and 
especially nested control flow) makes it difficult for me to 
understand what the code does (not to mention debugging it). 
Unfortunately, it can be difficult to eliminate (or hide) control 
flow without creating needless complexity in other parts of the 
program. For instance, Linus' "good taste" example uses pointers 
explicitly and I would argue that this too is "distasteful".


On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
One thing I've been trying to do lately when working with DMD 
is to separate code that gathers information from code that 
performs an action. (The former can then be made pure.) My code 
traditionally has it all interleaved together.


An obvious example of code that gathers information separated 
from code that performs an action is exceptions. :)

Re: Linus' idea of "good taste" code

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 26 October 2016 at 09:41:42 UTC, Walter Bright 
wrote:
6. Nearly all bugs can be fixed with under 10 lines of code, 
and quite a few with 1 line. It's always a red flag for me when 
a fix PR has 200+ lines of code (test case lines of code don't 
count, neither do comments).


I find the most elegant bug fixes tend to be the ones with an 
overall reduction of code.


Though, sometimes things are rotten to the core and that net 
change of -10 lines comes from a +330, -340 diff

Re: Linus' idea of "good taste" code

[Andrea Fontana via Digitalmars-d]

On Wednesday, 26 October 2016 at 09:41:42 UTC, Walter Bright 
wrote:
7. If you're stuck on a programming problem, go out for a jog. 
I often find the answer that way. What can I say, it works for 
me.


It's a common way to solve problem. Just concentrate yourself on 
something more pratical than problem-solving. It really works 
fine for me. When we have a hard problem to solve my boss always 
tell me to take a walk out of office or simple to go home to 
lunch. Then I come back with solution. It works.

Re: Linus' idea of "good taste" code

[Chris via Digitalmars-d]

On Wednesday, 26 October 2016 at 09:41:42 UTC, Walter Bright 
wrote:

On 10/25/2016 5:19 PM, bluecat wrote:



[snip]

I largely agree with your points 1.-7. (especially 1. and 7.). 
Also that gathering the data and acting upon it should be 
separate. However, principles might be at loggerheads. E.g. 
generics vs. specialization. Performance vs. fragmentation. Cf.


https://dpaste.dzfl.pl/dc8dc6e1eb53
vs.
https://dpaste.dzfl.pl/392710b765a9

(Andrei's improved search algorithm that got a performance boost 
through manual inlining).

Re: Linus' idea of "good taste" code

[Marco Leise via Digitalmars-d]

Am Tue, 25 Oct 2016 15:53:54 -0700
schrieb Walter Bright :

> It's a small bit, but the idea here is to eliminate if conditionals where 
> possible:
> 
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e
> 
> This is something we could all do better at. Making code a straight path 
> makes 
> it easier to reason about and test.
> 
> Eliminating loops is something D adds, and goes even further to making code a 
> straight line.

On a more controversial note, I sometimes replace nested
blocks of conditionals and loops with flat spaghetti code and
goto with verbose labels. There are situations where you can
explain straight forward what needs to be done first, second
and last, but special cases and loops make it hard to tell
from "normal" code.

  if (valueTooBig)
goto BreakBigValueDown;

ProcessValue:
  ...
  return;

  // == //

BreakBigValueDown: // makes big values manageable
  ...
  goto ProcessValue;


There is a concise piece of code that handles 90% percent
of the cases and another block for anything that requires
special handling. It can in theory also avoid costly memory
loads for rarely used code.

> One thing I've been trying to do lately when working with DMD is to separate 
> code that gathers information from code that performs an action. (The former 
> can 
> then be made pure.) My code traditionally has it all interleaved together.

Interesting.

-- 
Marco

Re: Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

On 10/26/2016 2:54 AM, Dicebot wrote:

I find it both funny and saddening how many reddit commentators
complained about Linus version of that code is over-complicated.

"Prefer clear code over smart code" principle is good in general but
sometimes it is over-applied to the point where incompetence gets
glorified. And this sucks.



Any coding principle rigidly applied leads to disaster.

Reminds me of:

1. newbie - follows the rules because he's told to
2. master - follows the rules because he understands them
3. guru - breaks the rules because he understands that they don't apply

Re: Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

On 10/25/2016 3:53 PM, Walter Bright wrote:

https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e


The Hacker News thread:

https://news.ycombinator.com/item?id=12793624

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/26/2016 12:53 AM, Walter Bright wrote:
> It's a small bit, but the idea here is to eliminate if conditionals
> where possible:
> 
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

I find it both funny and saddening how many reddit commentators
complained about Linus version of that code is over-complicated.

"Prefer clear code over smart code" principle is good in general but
sometimes it is over-applied to the point where incompetence gets
glorified. And this sucks.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

On 10/25/2016 5:19 PM, bluecat wrote:

Interesting, that's going in my tips.txt file. Quick question, if you don't
mind. What would be the top three things you've learned that significantly made
you a better programmer?


Ha, great question. Never thought about it before. Off the top of my head:

1. Never try to do two things at once, i.e. never mix:

   refactoring
   translation
   more than one bug fix at at time
   optimization
   feature addition

I sure endlessly beat people on github with clue-by-fours over this.


2. If the code looks ugly, it is guaranteed to not work properly. If you're 
stuck debugging someone else's code, look at the ugly bits first. (I've had 
several experienced developers tell me this, too.)



3. Anybody can write clever, complex code. It takes genius to write simple code.


4. Macros are like crack. The first hit feels great, but macros inevitably turn 
everything they touch into crap. It took me a lng time to learn this. Some 
years ago I made a concerted effort to purge macros from the dmd front end, and 
have been purging them from the back end. I've been very pleased with the results.



5. Global variables are the Spawn of Satan. (They make code very hard to reason 
about.)



6. Nearly all bugs can be fixed with under 10 lines of code, and quite a few 
with 1 line. It's always a red flag for me when a fix PR has 200+ lines of code 
(test case lines of code don't count, neither do comments).



7. If you're stuck on a programming problem, go out for a jog. I often find the 
answer that way. What can I say, it works for me.

Re: Linus' idea of "good taste" code

[H. S. Teoh via Digitalmars-d]

On Tue, Oct 25, 2016 at 03:53:54PM -0700, Walter Bright via Digitalmars-d wrote:
> It's a small bit, but the idea here is to eliminate if conditionals where 
> possible:
> 
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e
> 
> This is something we could all do better at. Making code a straight
> path makes it easier to reason about and test.

Not only easier to reason about, but probably performs better too.
Conditionals introduce pipeline hazards. (Though, arguably, not very
significant here because the loop would dominate the running time.)


> Eliminating loops is something D adds, and goes even further to making
> code a straight line.
> 
> One thing I've been trying to do lately when working with DMD is to
> separate code that gathers information from code that performs an
> action. (The former can then be made pure.) My code traditionally has
> it all interleaved together.

Separation of concerns is a typical "good taste" practice. It's why the
range-based pipeline idiom is so effective. When you compound multiple
concerns into a single piece of code, it inevitably gets tangled into a
complex mess that has lots of room for bugs to hide in. It's that whole
philosophy with Jackson Structured Programming again: make your code
structure 1-to-1 with your data structure, and edge cases and ad hoc
complexities vanish, along with their respective bug potentials.

If the input structure doesn't match the code structure for whatever
reason, say for algorithmic reasons, the best approach is to transform
the data into a matching structure first, then operate on it. I.e., your
"gather data, then operate on it" idea.  Trying to do both at the same
time typically leads to well-known warning signs: boolean flags,
recycled variables with conflicting meanings, proliferating
if-statements, complex looping conditions, etc., all the result of ad
hoc attempts at resolving the structure conflict between data and code.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you 
wish you hadn't.

Re: Linus' idea of "good taste" code

[bluecat via Digitalmars-d]

On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if 
conditionals where possible:


https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

This is something we could all do better at. Making code a 
straight path makes it easier to reason about and test.


Eliminating loops is something D adds, and goes even further to 
making code a straight line.


One thing I've been trying to do lately when working with DMD 
is to separate code that gathers information from code that 
performs an action. (The former can then be made pure.) My code 
traditionally has it all interleaved together.


Interesting, that's going in my tips.txt file. Quick question, if 
you don't mind. What would be the top three things you've learned 
that significantly made you a better programmer?

Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

It's a small bit, but the idea here is to eliminate if conditionals where 
possible:

https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

This is something we could all do better at. Making code a straight path makes 
it easier to reason about and test.


Eliminating loops is something D adds, and goes even further to making code a 
straight line.


One thing I've been trying to do lately when working with DMD is to separate 
code that gathers information from code that performs an action. (The former can 
then be made pure.) My code traditionally has it all interleaved together.