On Thursday, 5 May 2016 at 21:20:36 UTC, QAston wrote:
> https://en.wikipedia.org/wiki/Sokal_affair
>
> I think IT is going to be more resistant to this nonsense than social sciences. It is more competitive and verified by customers, so at least in theory the worst ideas will die.

Huh? Sokal affair can be prevented by censorship. Do you want it in IT? You make it live by making commotion around it.

> C+=[2](someone remade the repo after ban from github/bitbucket) is just one more parody that's going to become reality.

And why C+= should be censored? If people believe there is some sort of oppression in programming languages there should be a comprehensive answer to that in the form of C+=.

On Friday, 6 May 2016 at 10:10:22 UTC, Kagamin wrote:
> On Thursday, 5 May 2016 at 21:20:36 UTC, QAston wrote:
>> https://en.wikipedia.org/wiki/Sokal_affair
>>
>> I think IT is going to be more resistant to this nonsense than social sciences. It is more competitive and verified by customers, so at least in theory the worst ideas will die.
>
> Huh? Sokal affair can be prevented by censorship. Do you want it in IT? You make it live by making commotion around it.
>
>> C+=[2](someone remade the repo after ban from github/bitbucket) is just one more parody that's going to become reality.
>
> And why C+= should be censored? If people believe there is some sort of oppression in programming languages there should be a comprehensive answer to that in the form of C+=.

Sokal affair is just a demonstration of how far detached from reality are postmodernists, refering to cited post. I'm all for parodies like this, no idea why you think otherwise.

On Friday, 6 May 2016 at 12:33:10 UTC, QAston wrote:
> Sokal affair is just a demonstration of how far detached from reality are postmodernists, refering to cited post.

Those attached to objective reality are usually detached from subjective reality. That's the mistake postmodernism fixes (or tries). Not much can be added to knowledge of objective reality found by classic and modernism, but that's what they are limited to.

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 three methods to communicate blocks to the compiler: curly braces, significant whitespace (Python, Haskell), or an "end" keyword (Ruby, Pascal). Which one you prefer is subjective.
>
> You mention Facebook and face recognition. I have not seen anyone try machine learning for parsing. It would probably be a fun project, but not a practical one.
>
> You wonder that understanding structured text should be a solved problem. It is. You need to use a formal language, which programming languages are. English for example is much less structured. There easily are ambiguities. For example:
>
>   I saw a man on a hill with a telescope.
>
> Who has the telescope? You or the man you saw? Who is on the hill?
>
> As a programmer, I do not want to write ambiguous programs. We produce more than enough bugs without ambiguity.

Thanks for the example! So you laid out the three options for signifying blocks. Then you said which one you prefer is subjective, but that you don't want to write ambiguous programs. Do you think that the curly braces and semicolons help with that?

So in your example, I figure bar's status is language-defined, and programmers will be trained in the language in the same way they are now. I've been sketching out a new language, and there are a couple of ways I could see implementing this.

First, blocks of code are separated by one or more blank lines. No blank lines are allowed in a block. An if block would have to terminate in an else statement, so I think this example just wouldn't compile. Now if we wanted two things to happen on an if hit, we could leave it the way you gave where the two things are at the same level of indentation. That's probably what I'd settle on, contingent on a lot of research, including my own studies and other researchers', though this probably isn't one of the big issues. If we wanted to make the second thing conditional on success on the first task, then I would require another indent. Either way the block wouldn't compile without an else.

I've been going through a lot of Unicode, icon fonts, and the Noun Project, looking for clean and concise representations for program logic. One of the ideas I've been working with is to leverage Unicode arrows. In most cases it's trivial aesthetic clean-up, like → instead of ->, and a lot of it could be simple autoreplace/autocomplete in tools. For if logic, you can an example of bent arrows, and how I'd express the alternatives for your example here: http://i1376.photobucket.com/albums/ah13/DuartePhotos/if%20block%20with%20Unicode%20arrows_zpsnuigkkxz.png

On Saturday, 14 May 2016 at 03:19:51 UTC, Joe Duarte wrote:

> I've been going through a lot of Unicode, icon fonts, and the Noun Project, looking for clean and concise representations for program logic. One of the ideas I've been working with is to leverage Unicode arrows. In most cases it's trivial aesthetic clean-up, like → instead of ->, and a lot of it could be simple autoreplace/autocomplete in tools. For if logic, you can an example of bent arrows, and how I'd express the alternatives for your example here: http://i1376.photobucket.com/albums/ah13/DuartePhotos/if%20block%20with%20Unicode%20arrows_zpsnuigkkxz.png

there's a keyboard for those types of programs ;-)

http://www.dyalog.com/uploads/images/Business/products/us_rc.jpg

(APL keyboard)

On Saturday, 14 May 2016 at 12:49:19 UTC, Abdulhaq wrote:
> there's a keyboard for those types of programs ;-)
>
> http://www.dyalog.com/uploads/images/Business/products/us_rc.jpg

One of the things I do with my custom terminal emulator and text scripts is make those common unicode characters easier to type but I actually often forget where they are... generally, I prefer typing out "theta" or "->" to θ or → (aside from some of my fonts not even supporting such characters!) is just that they are really easy on the keyboard and I know what the word means anyway.

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 instructions on the same line (the only utility of commas) ends up being a bad idea. But it's part of those things that have such an inertia that you just wouldn't ever had heard of D if it hadn't had it I think. Having commas was not decided by their intrinsic usefulness but by the choice to target the C/C++ market.

Good point that line-ending semicolons carry no information if they're on every line (I assume you meant semicolons instead of commas).

An important point that I think is undocumented: text editors don't let you inhabit a new line unless you press Enter on the line above. In other words, you can't have a new line by using the down arrow or some other means. When I first learned programming, I was stumped by how a compiler was line-aware, how it knew when a line was truly ended, and what counted as line qua line (I wrongly assumed you could down-arrow to a new line). It's an invisible character by default, and they don't tell you how text editors behave. This comes up a bit in Markdown and in how people are inconsistently defining a "hard" vs "soft" line break.


> But Python sacrifices a *lot* of performances to do that. D has its own way and different goals. Being performance-friendly is one of them and that sometimes gets you with long functions and ugly hacks. When it comes to that having curly braces (well any kind of delitmiter really) is a great thing.

It's not clear how curly braces deliver better performance. Anything expressed with curly braces can be expressed without them -- i.e. you could design a language in which that were true. Walter mentioned the issue of redundancy, which seems reasonable, but that doesn't bear on the performance issue. A good example of a non-curly brace compiled language is Crystal, at least last time I checked. Python loses a lot for being a text-executing interpreted language. What an interpreter does -- in comparison to a JIT compiler -- is wildly underdocumented. The standard answer to a lot of people on the web asking for an explanation is that a JIT compiles down to native code or machine code, while an interpret just interprets the code, or sometimes you'll see "executes it directly". Big gaping hole on how it gets down to machine code. But starting with text is crippling. I love Walter's decision to have pre-compiled modules instead of text headers -- I didn't realize that C compilers were literally parsing all this text every time.

Python could get some big wins from a well-designed IR and follow-on back-end code generator, or a JIT, or some combo. This is obviously not a new idea, but no one seems willing to do it in a professional, focused, and expensive way. Unladen Swallow was weird in that you had a couple of kids, undergrad students who had no experience trying to build it all. It's weird how casual and half-assed a lot of software projects are. If I were trying to do this, I'd want to assemble the Avengers -- I'd want a large team of elite software developers, architects, and testers, enough to do it in a year. That's a rare setup, but it's how I would do it if I were Microsoft, Google, FB, et al -- if I were willing to spend $20 million on it, say. Pyjion might become something interesting, but right now it looks pretty casual and might be the kind of thing where they'll a lot of outside open-source developer help (https://github.com/Microsoft/Pyjion). Pyston is only focused on Python 2, which is rearview mirror thing.

By the way, anyone should be able to create a version of C, D, or Go that doesn't use curly braces or semicolons, just by enforcing some rules about indentation and maybe line length that are already adhered to by virtue of common coding standards (e.g. blocks are typically indented; and I realize Go doesn't require semicolons). If we looked at typical code examples in almost any language like C, C#, D, Java, Swift, and we systematically encoded their meaning, reducing them down to a concise and non-redundant form, we'd find lots of redundancy and a lot of textual dead code, so to speak. This would be true even without semicolons and braces. There's still a lot for a compiler or any interpretive agent to go on.

On 05/15/2016 01:01 AM, Joe Duarte wrote:
> Good point that line-ending semicolons carry no information if they're
> on every line (I assume you meant semicolons instead of commas).
[...]
> By the way, anyone should be able to create a version of C, D, or Go
> that doesn't use curly braces or semicolons, just by enforcing some
> rules about indentation and maybe line length that are already adhered
> to by virtue of common coding standards (e.g. blocks are typically
> indented; and I realize Go doesn't require semicolons). If we looked at
> typical code examples in almost any language like C, C#, D, Java, Swift,
> and we systematically encoded their meaning, reducing them down to a
> concise and non-redundant form, we'd find lots of redundancy and a lot
> of textual dead code, so to speak. This would be true even without
> semicolons and braces. There's still a lot for a compiler or any
> interpretive agent to go on.

On semicolons:

There is a promoted style in D that does not use semicolons on every line. This example is on the dlang.org home page:

----
// Sort lines
import std.stdio, std.array, std.algorithm;

void main()
{
    stdin
        .byLineCopy
        .array
        .sort!((a, b) => a > b) // descending order
        .each!writeln;
}
----

A leading dot is valid, too. (It means module scope rather than local scope.) So without semicolons, there would ambiguities:

----
foo()
.writeln()
----

`foo(); .writeln();` or `foo().writeln();`?