Jump to page: 1 217  
Page
Thread overview
Worst ideas/features in programming languages?
Oct 11
russhy
Oct 12
9il
Oct 11
Johan
Oct 11
jmh530
Oct 11
jfondren
Oct 11
Dukc
Oct 11
russhy
Oct 11
russhy
Oct 13
russhy
Oct 11
bachmeier
Oct 11
drug
1 day ago
SealabJaster
1 day ago
SealabJaster
1 day ago
SealabJaster
1 day ago
claptrap
1 day ago
Imperatorn
1 day ago
claptrap
12 hours ago
claptrap
12 hours ago
bauss
11 hours ago
ClapTrap
1 hour ago
ClapTrap
20 minutes ago
Ola Fosheim Grøstad
13 hours ago
Guillaume Piolat
11 hours ago
ClapTrap
10 hours ago
Guillaume Piolat
1 hour ago
ClapTrap
Oct 11
RazvanN
Oct 11
jmh530
Oct 12
jmh530
Oct 11
monkyyy
Oct 12
jfondren
Oct 12
monkyyy
Oct 14
jfondren
Oct 11
apz28
Oct 12
surlymoor
Oct 12
bauss
Oct 12
bauss
Oct 12
user1234
Oct 12
zjh
Oct 12
Kagamin
Oct 13
russhy
Oct 14
russhy
Oct 12
jmh530
Oct 12
surlymoor
Oct 13
user1234
Oct 12
sarn
Oct 14
bauss
Oct 14
bauss
Oct 13
deadalnix
Oct 14
JN
Oct 14
bauss
Oct 14
IGotD-
Oct 15
Antonio
Oct 15
IGotD-
Oct 15
Antonio
Oct 15
bauss
Oct 15
deadalnix
Oct 15
russhy
Oct 15
russhy
Oct 15
deadalnix
Oct 15
SomeGuy
Oct 15
IGotD-
Oct 15
Araq
Oct 15
IGotD-
Oct 15
Araq
Oct 16
IGotD-
Oct 16
Araq
Oct 15
SomeGuy
Oct 15
deadalnix
Oct 15
deadalnix
Oct 16
russhy
Oct 16
deadalnix
Oct 16
deadalnix
Oct 18
deadalnix
Oct 18
deadalnix
Oct 18
russhy
Oct 18
deadalnix
Oct 18
russhy
6 days ago
bauss
6 days ago
Tejas
5 days ago
Kagamin
5 days ago
Tejas
5 days ago
Kagamin
Oct 16
russhy
Oct 16
deadalnix
Oct 15
russhy
Oct 16
Rumbu
5 days ago
bauss
5 days ago
Andrea Fontana
5 days ago
Imperatorn
5 days ago
SealabJaster
5 days ago
IGotD-
5 days ago
SealabJaster
October 11

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language
  • Worst features (in your opinion) in D
  • Features you'd like to see in D

Ideas? Examples?

Thanks!

October 11

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language
  • Worst features (in your opinion) in D
  • Features you'd like to see in D

Ideas? Examples?

Thanks!

Objectively worst feature: mutability/referenceability by default. It takes away so much optimization potential and introduces so many opportunities for state changes. var = value should be opt-in. Just as importantly, &var should be opt-in.

My D hobbyhorse, of course, is __traits(compiles) (see my last DConf talk) and the SFINAE-like mess that it enables but doesn't give us the tools to address. "Why did the template not instantiate?" Who knows~ That syntax error got suppressed five instantiations down.

And there's obvious stuff like the half-baked immutable that works in about half the stdlib and a smaller fraction of libraries. D2 const was a mistake, cmv. (Nonreferenceability allows safe reassignment of immutable struct member fields, btw!)

But I'm actually convinced that the worst thing is the lack of implicit construction for sumtypes. Because when you try to actually use sumtypes, you end up with stuff like Nullable!MySumType(MySumType(MemberType("Hello World"))). All over the place. And it adds no value! The whole point of MySumType is that it's "one of n types, including MemberType". Writing out the full type of a nested container type like that adds nothing of value.

Sumtypes should be built-in, and they should implicitly construct from its member types.

PS: But staring at this post interface, what I want the most right now - a "Discard all drafts" button. :)

October 11

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language
  • Worst features (in your opinion) in D

Two things that immediately come to mind:

  • unittest. Clutters code reading, discourages extensive testing (because of said clutter), discourages testing inside a user's module, complicates runtime and compiler, framework cannot be developed separate from language runtime, ...

  • Implicit pointer/reference type of classes. While I think the forced reference type of classes is a good idea (when passing as function argument), I think it was a very bad idea to remove the * from notation. It makes code impossible to interpret without looking up a user-defined type.

-Johan

October 11

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language

Indirect method notation in Perl: https://stackoverflow.com/questions/11695110/why-is-this-program-valid-i-was-trying-to-create-a-syntax-error/11695310#11695310

wantarray in Perl, where e.g. reverse() either reverses its list of arguments (a list of one argument $a in the following program--a noop) or it reverses the joined string of its list of arguments (the single string $a in the following the program) , depending on what the caller wants:

sub foo {
    my ($a) = @_;
    reverse $a;
}

print foo("unchanged"), "\n";  # output: unchanged
my $changed = foo("changed");
print $changed, "\n";          # output: degnahc

Aliasing subroutine parameters in Perl: sub foo { my $arg = shift; } is not the same thing as sub foo { my ($arg) = @_; } and I can no longer remember why it's super critically important that you use the second form by default.

Autovivification in Perl - usually desirable, and D has it to an extent in AAs. But then there's this:

sub add {
    my ($table, $key) = @_;
    $table->{$key} = 1;
}

my $table;           # undef
add($table, "one");  # undef autovivifies into a hashref ... only within add()
die "that silently did nothing" if exists $table{one};
$table = {};         # an empty hashref
add($table, "two");  # empty hashref is mutated by add()
print $table{two};

Overriding 'built in' functions. Does stat() return the list of fields enumerated in 'perldoc -f stat' or does it return an object? Better check and see if the program you're maintaining used File::stat or not.

$_ as the default argument in Perl. Literally once a month I write this code:

open my $f, '<', 'open some file to read'
    or die "Tried to open 'some file to read' and failed : $!";
while (defined(my $line = <$f>)) {
    next unless /oh goddamnit this regex is applying to $_ and not $line/;
    do_stuff;
}

Perl has a lot of "wow, that was a horrible idea! Let's fix it by adding a new syntax, encouraging people to use that instead, and then leaving this horrible idea in the language forever." misfeatures. The separate '<' in the previous example is some new syntax for opening files. The old syntax lets you write tools that will truncate /etc/passwd or spawn arbitrary subprocesses if given a malicious filename. At least those dangerous tools never stopped working due to the language updating and breaking them, right?

>
  • Worst features (in your opinion) in D
  • Features you'd like to see in D

Maybe it's not surprising by this point of this post, but I'm pretty happy with D.

I would like some easy way to make sure I haven't accidentally used 80-bit floats in a D program.

October 11

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language
  • Some C standard library functions. gets is the worst one, but atof and atoi are pretty useless too.

  • The feature of some early C compilers that only the first 7 characters of an identifier are significant.

  • C casting and C++ template syntaxes.

  • Disallowed free functions in Java and C#

  • More than one feature of C# structs.

>
  • Worst features (in your opinion) in D
  • Integer promotion without at least letting to assign the result back to original width without a cast

  • Autodecoding. It would not be as bad if string literals were of some sort of wrapper type over the data, but autodecoding a plain array type just sucks.

>
  • Features you'd like to see in D
  • The Phobos versioning scheme that is already in the works.

  • Some way to enable preview/revert switches per module as opposed to per compilation. And same for autodecoding if possible.

  • More compatibility between compiler / standard library versions in general.

>

Ideas? Examples?

  • Perhaps we should have a common agreement on what compiler versions should be used when long-term support for code is the goal. For example, we could agree on 2.084, 2.090, 2.096, 2.102 etc.
October 11

On Monday, 11 October 2021 at 16:12:59 UTC, FeepingCreature wrote:

>

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language
  • Worst features (in your opinion) in D
  • Features you'd like to see in D

Ideas? Examples?

Thanks!

Objectively worst feature: mutability/referenceability by default. It takes away so much optimization potential and introduces so many opportunities for state changes. var = value should be opt-in. Just as importantly, &var should be opt-in.

My D hobbyhorse, of course, is __traits(compiles) (see my last DConf talk) and the SFINAE-like mess that it enables but doesn't give us the tools to address. "Why did the template not instantiate?" Who knows~ That syntax error got suppressed five instantiations down.

And there's obvious stuff like the half-baked immutable that works in about half the stdlib and a smaller fraction of libraries. D2 const was a mistake, cmv. (Nonreferenceability allows safe reassignment of immutable struct member fields, btw!)

But I'm actually convinced that the worst thing is the lack of implicit construction for sumtypes. Because when you try to actually use sumtypes, you end up with stuff like Nullable!MySumType(MySumType(MemberType("Hello World"))). All over the place. And it adds no value! The whole point of MySumType is that it's "one of n types, including MemberType". Writing out the full type of a nested container type like that adds nothing of value.

Sumtypes should be built-in, and they should implicitly construct from its member types.

PS: But staring at this post interface, what I want the most right now - a "Discard all drafts" button. :)

  • features that require a GC (associative array)

  • class (reference type)

>

Sumtypes should be built-in, and they should implicitly construct from its member types.

I 100% agree with you

Tagged union SHOULD be built in, telling people to import a package and use them like templates is the best way to discourage people from getting interested in the language

When other "modern" languages don't have the problem since it's built in feature

The positive side of std.sumtype is it showcase the capabilities of the language to implement new features on user land, BUT, for sumtype, nobody should have to go that road..

Same for Nullable/Optional in my opinion

October 11

On Monday, 11 October 2021 at 17:06:38 UTC, Johan wrote:

>

[snip]

  • unittest. Clutters code reading, discourages extensive testing (because of said clutter), discourages testing inside a user's module, complicates runtime and compiler, framework cannot be developed separate from language runtime, ...

Nothing prevents you from pulling out the unittests (except maybe documented ones) and putting them in a separate file or folder structure. In fact, it should probably be more commonly done...

October 11
>

Worst features implemented in a non-toy language

It's been a while i haven't used anything other than D, so i don't have much to say, i'll need to research to remember first

On top of my head, i think the worst feature in any language is C/C++ header system

Sometimes, in rare occasions it can be handy, but most of the time it is a pain in the butt

>

Worst features (in your opinion) in D

- class (reference type)
- GC as a feature
- !() for templates (not really a feature, more like a syntax issue, way to similar to functions)
- being abot to use ! with optional parentheses, countless times i got bit by:
    ``Array!int* array;``  but i wanted ``Array!(int)* array;`` instead..
>

Features you'd like to see in D

- tagged union (built in, not as std/lib)
- interface / signature for structs (built in, not as std/lib)
    - alternatively, reintroduce the * for classes
- enum literals (being able to omit the enum name)
    ex:
        ```d
        enum MyEnum { A, B, C}
        MyEnum e = :A;
        my_function(:A);
        switch (e)
        {
        case :A: break;
        }
        // could be :, ., $, ! but that is not the point
        '''
October 11

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language

C's pointer notation is too stupid for words. (I understand how it works. I've been using it for decades. Please no explanations.)

Writing functions like this is horrible:

int timesTwo(int *x) {
	return 2 * *x;
}

When you learn C, you ask what the *x is. It's an int. That makes sense. That's why it's int *x. Okay, let's call that function:

int main() {
	printf("%d\n", timesTwo(4));
	return 0;
}

expected ‘int *’ but argument is of type ‘int’

Okay, let's try this:

int main() {
	int z = 4;
	printf("%d\n", timesTwo(&z));
	return 0;
}

8

So *x is an int, but you have to pass &z, which is not an int, as the argument. The only way this can't be confusing to someone learning it for the first time is if they're memorizing syntax.

October 11
On 11.10.2021 22:15, bachmeier wrote:
> On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:
>> I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:
>>
>> * Worst features implemented in a non-toy language
> 
> C's pointer notation is too stupid for words. (I understand how it works. I've been using it for decades. Please no explanations.)
> 
> Writing functions like this is horrible:
> 
> ```
> int timesTwo(int *x) {
>      return 2 * *x;
> }
> ```
> 
> When you learn C, you ask what the `*x` is. It's an int. That makes sense. That's why it's `int *x`. Okay, let's call that function:
> 
> ```
> int main() {
>      printf("%d\n", timesTwo(4));
>      return 0;
> }
> ```
> 
> `expected ‘int *’ but argument is of type ‘int’`
> 
> Okay, let's try this:
> 
> ```
> int main() {
>      int z = 4;
>      printf("%d\n", timesTwo(&z));
>      return 0;
> }
> ```
> 
> `8`
> 
> So `*x` is an int, but you have to pass `&z`, which is not an int, as the argument. The only way this can't be confusing to someone learning it for the first time is if they're memorizing syntax.

I would say that `x` is a pointer to int and `*x` is a dereferenced pointer to int. 4 is an int value and it can not be treated as a dereferenced pointer to int. So you need to create an int value, take the pointer to it and then pass it to the function.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11