On Sunday, 15 May 2016 at 10:52:47 UTC, Timon Gehr wrote:
On 15.05.2016 05:02, Joe Duarte wrote:
Type systems are quite arbitrary and primitive
That may apply to the popular ones.
-- we could've moved to real-world types
The "real world" is complex and there are bound to be some
modeling
On Friday, 13 May 2016 at 22:13:50 UTC, QAston wrote:
Mainstream PL syntax is extremely unintuitive and poorly
designed by known pedagogical, epistemological, and
communicative science standards. The vast majority people who
are introduced to programming do not pursue it (likely true of
many
On Tuesday, 10 May 2016 at 13:40:30 UTC, Chris wrote:
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:
[snip]
Let me give you a sense of the sorts of issues I'm thinking
of. Here is a C sample from ProgrammingSimplified.com. It
finds the frequency of characters in a string:
int main()
On Tuesday, 3 May 2016 at 22:17:18 UTC, cym13 wrote:
In my opinion putting commas at the end of a line is useless:
if it happens at the end of each line (not counting
closing-braces ones) then the effective quantity of information
brought is null, and in more than one case chaining
instructio
On Tuesday, 3 May 2016 at 12:47:42 UTC, qznc wrote:
The parser needs information about "blocks". Here is an example:
if (x)
foo();
bar();
Is bar() always executed or only if (x) is true? In other
words, is bar() part of the block, which is only entered
conditionally?
There are th
On Monday, 9 May 2016 at 20:17:40 UTC, ag0aep6g wrote:
Am 09.05.2016 um 21:09 schrieb Joe Duarte:
4. We switch the person or voice from an imperative "do this"
as in
printf, to some sort of narrator third-person voice with
"gets".
"gets" is still imperative. It's short for "get string". Not
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:
Don Clugston pointed out in his DConf 2016 talk that:
float f = 1.30;
assert(f == 1.30);
will always be false since 1.30 is not representable as a
float. However,
float f = 1.30;
assert(f == cast(float)1.30);
will b
On Monday, 9 May 2016 at 20:29:12 UTC, Joe Duarte wrote:
On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote:
I'd also be surprised if you find an empirical gender gap
after controlling for programming language syntax, too. Even
if we grant that PL syntax is suboptimal, why would that
On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote:
I'd also be surprised if you find an empirical gender gap after
controlling for programming language syntax, too. Even if we
grant that PL syntax is suboptimal, why would that result in a
gender bias? But, hey, you never really know u
Hi all,
As I mentioned on the other thread where I asked about D syntax,
I'm a social scientist about to launch some studies of the
effects of PL syntax on learnability, motivation to pursue
programming, and differential gender effects on these factors.
This is a long post – some of you wante
On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:
Would it be difficult to compile the clean version?
You realize your bias is showing very strongly in the wording
of this question, right? I don't agree the naked version is
On Tuesday, 3 May 2016 at 04:23:48 UTC, Walter Bright wrote:
On 5/2/2016 8:48 PM, Joe Duarte wrote:
Why are curly braces and semicolons necessary? What
information do they
carry that a compiler could not otherwise reliably obtain?
You are correct in that they are (mostly) redundant. Some
amb
Hi all,
I'm a social scientist and I'm preparing some studies on the
effects of programming language syntax on learning, motivation to
pursue programming, as well as any disproportionate effects that
PL syntax has on the appeal of programming to women (more on the
latter in a separate post).
On Saturday, 23 April 2016 at 10:40:12 UTC, Johan Engelen wrote:
On Monday, 18 April 2016 at 00:27:06 UTC, Joe Duarte wrote:
Someone else said talked about marking "Broadwell" and other
generation names. As others have said, it's better to specify
features. I wanted to chime in with a couple
On Tuesday, 5 April 2016 at 10:27:46 UTC, Walter Bright wrote:
Besides, I think it's a poor design to customize the app for
only one SIMD type. A better idea (I've repeated this ad
nauseum over the years) is to have n modules, one for each
supported SIMD type. Compile and link all of them in, t
15 matches
Mail list logo
