August 06, 2015 Re: Rant after trying Rust a bit | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | On 08/06/2015 07:13 PM, jmh530 wrote: > On Thursday, 6 August 2015 at 14:14:30 UTC, Jonathan M Davis wrote: >> In general, I would have expected it to be a total disaster if a >> language used any non-ASCII characters in its syntax. > > I still think it would be...not everyone uses the same editor. I had to > look up how to do it in Notepad++. It requires knowing the Unicode key. > Not exactly user-friendly. Not a Windows user, but I bet it wouldn't take long to find a better solution. > I wouldn't have an issue if the editor had a > layout like Lyx. Configuration is an O(1) operation. The constant becomes smaller after the first three users of the hypothetical language have set up their environment. |
August 06, 2015 Re: Rant after trying Rust a bit | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On 08/06/2015 07:50 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote: > On Wednesday, 5 August 2015 at 19:56:37 UTC, Timon Gehr wrote: >> On 08/05/2015 07:32 PM, deadalnix wrote: >>> Mathematical language is geared toward generality and correctness, not >>> practicality. That makes sens in the context of math, that do not in the >>> context of every day programming. >> >> I don't see what you are trying to get at here, but I guess it is >> almost entirely unrelated to choosing a notation for string >> concatenation. > > Well, I don't think practicality is the main issue, but the mnemonic > aspect of syntax is important. > > It is not unreasonable to make the identity of operators/functions > consist of both name and parameter types like in C++ and D. So you don't > have "+" as the operator name, you have "+(int,int)" and > "+(string,string)". > ... Certainly, but overloading is not always a good idea. > It has been argued that functional languages would benefit from teaching > functional programming in a less mathematical manner (e.g. talk about > "callbacks" rather than "monads" etc): > > https://youtu.be/oYk8CKH7OhE > That's not less "mathematical". It is less abstract, maybe. Also, I think he is optimizing for people who pick up the language on their own. (i.e. it is not really about "teaching" in any traditional sense.) |
October 15, 2015 Re: Rant after trying Rust a bit | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 26/07/2015 23:58, deadalnix wrote: > On Sunday, 26 July 2015 at 18:13:30 UTC, Tobias Müller wrote: >> Alix Pexton <alix.DOT.pexton@gmail.DOT.com> wrote: >>> On 25/07/2015 9:48 PM, Walter Bright wrote: >>> >>>> Unfortunately, Bruce Eckel's seminal article on it >>>> http://www.mindview.net/Etc/Discussions/CheckedExceptions has >>>> disappeared. Eckel is not a Java code monkey, he wrote the book >>>> Thinking >>>> In Java >>>> http://www.amazon.com/gp/product/0131002872/ >>>> >>> >>> >>> https://web.archive.org/web/20150515072240/http://www.mindview.net/Etc/Discussions/CheckedExceptions >>> >> >> This is article not convincing at all. His argument is basically "Most >> programmers are sloppy and tend to catch and ignore checked exceptions." >> > > No it is that checked Exception encourage this behavior. > > Ultimately, checked exception are a failure as they completely break > encapsulation. Let's say you have a logger interface. Some of its > implementation will just send the log to Dave Null, some write it in a > file, some will send it over the network to some tailor, and so on. The > class of error that arise from each is completely different and cannot > be listed exhaustively at the interface level in any meaningful way. > Then define the logger interface as throwing a generic Exception class. (a class that sits at the top of the hierarchy of the other Exceptions) -- Bruno Medeiros https://twitter.com/brunodomedeiros |
July 11, 2016 Re: Rant after trying Rust a bit | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Thursday, 6 August 2015 at 06:54:45 UTC, Walter Bright wrote: > On 8/3/2015 2:19 AM, Max Samukha wrote: >> The point is that '+' for string concatenation is no more of an 'idiot thing' >> than '~'. > > Sure it is. What if you've got: > > T add(T)(T a, T b) { return a + b; } > > and some idiot overloaded + for T to be something other than addition? That is a general problem with structural typing. Why not assume that if a type defines 'length', it must be a range? Then call an idiot everyone who defines it otherwise. I admit that special treatment of '+' is justified by its long history, but 'idiot thing' is obviously out of place. BTW, it happens that '+' does not always have to be commutative: https://en.wikipedia.org/wiki/Near-ring https://en.wikipedia.org/wiki/Ordinal_arithmetic#Addition |
July 13, 2016 Re: Rant after trying Rust a bit | ||||
---|---|---|---|---|
| ||||
Posted in reply to Max Samukha | On Monday, 11 July 2016 at 17:02:50 UTC, Max Samukha wrote:
> BTW, it happens that '+' does not always have to be commutative: https://en.wikipedia.org/wiki/Near-ring
> https://en.wikipedia.org/wiki/Ordinal_arithmetic#Addition
Yes, although concatenations ought to be «*»... and the empty string «""» the identity (1).
e.g. a free monoid:
"abc" * "d" == "abcd"
"abc"*"" == "abc"
"abc"*""*"" == "abc"
Then if you want to represent a set of alternate sets like a regexp «ab|cd» you could replace the alternative operator «|» with «+» and let the empty set «{}» be zero (0). Thus get a semiring:
( {"a"} + {"b"} ) + {"c"} == {"a"} + ( {"b"} + {"c"} ) == {"a" + "b" + "c"}
{} + {"a"} == {"a"} + {} == {"a"}
{"a"} + {"b"} == {"b"} + {"a"} == {"a" + "b"}
( {"a"} * {"b"} ) * {"c"} == {"a"} * ( {"b"} * {"c"} ) == {"abc"}
{"a"} * ({"b"} + {"c"}) == ({"a"} * {"b"}) + ({"a"} * {"c"}) == { "ab" + "ac" }
({"a"} + {"b"}) * {"c"} == ({"a"} * {"c"}) + ({"b"} * {"c"}) == {"ab + "bc" }
{""} * {"a"} == {"a"} * {""} == {"a"}
{} * {"a"} == {"a"} * {} == {}
Sortof...
|
July 14, 2016 Re: Rant after trying Rust a bit | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Wednesday, 13 July 2016 at 21:33:39 UTC, Ola Fosheim Grøstad wrote:
> Then if you want to represent a set of alternate sets like a
Typo: a set of alternative strings.
|
Copyright © 1999-2021 by the D Language Foundation