531–539 of 539 posts
> You can write # 2001-08-12 # to mean the date 2001-08-12, instead of writing something annoying like Date(2001, 8, 12) I like this article but oh man dates just trigger me. Such a missed opportunity to use an unambiguous date example like 2001-08-13
Oh the joys of being a school administrator with a new international student whose birth date is given as 3/7/5.
Earlier quoted context omitted.
I really like Scala’s `val` vs `var`.
Okay, that would confuse me. Looks very similar and easy to overlook.
Earlier quoted context omitted.
> A big problem, among many, with doing that is that you leak implementation details out of the abstraction. If, to stick with your example, you have a function that helps you with reading files, the caller shouldn't care where the data is stored. Today it might be the local filesystem, tomorrow S3, and when you make that change nothing about the rest of the program should break. This would lead to the situation wher…
> Which is know to be a very bad design. If your abstraction leaks that the implementation is a local call, and then you try and change that later, unquestionably. Again, you need to avoid leaking implementation details, which is too why you can't just add a try operator and make it automatically useful. Any leak of any kind in your abstraction will make life miserable later. Don't let your abstraction leak. > Yeah,…
Earlier quoted context omitted.
just allow nice infix functions :) (which is allowing nice postfix ones with currying) Scala does it pretty well. and nowadays finally the function names don't require a PhD in ancient Egyptian hieroglyph decoding. so requiring alphanum names for functions is pretty important imho. (sure it's okay if it's just a stern lint warning and the developer has to opt-in. but searching for iteratee is easier than searching fo…
Scala does a lot right here, but it's supper annoying with its arbitrary limitations for how you can name your methods. If I want a method called `U+1F602`¹ it's not the business of the language to judge that. --- ¹ the actual glyph, which gets filtered out here, also for no reason
But I'm also a firm believer of providing escape hatches. So it should be just a toggle in the project/file/directory to enable whatever behavior. And a very good language would require a human readable explanation for these, so when the developer says
allowEmojisInCode = true "we decided to allow emojis to make our happy DSL, see emoji reference at https://..../...."
downstream users/readers of the code are in a much better position than with just 30000 lines of emojis :)
Earlier quoted context omitted.
Scala does a lot right here, but it's supper annoying with its arbitrary limitations for how you can name your methods. If I want a method called `U+1F602`¹ it's not the business of the language to judge that. --- ¹ the actual glyph, which gets filtered out here, also for no reason
I think it's okay for a language to help guide its users toward "better code" (of course Rust is the big one for this). But I'm also a firm believer of providing escape hatches. So it should be just a toggle in the project/file/directory to enable whatever behavior. And a very good language would require a human readable explanation for these, so when the developer says allowEmojisInCode = true "we decided to allow e…
Scala does not even let most people on the world express code in their native language, and that in the age of Unicode! Sorry, but that's a little to much of "we know better than you what's good for you" kind of thing.
Of course I know where this comes form: Scala is used broadly in education. There it's good to not allow the students to do all kind of "madness".
But Scala is also mostly used by seasoned professionals in real world settings. (Just have a look at the latest survey, found on the Scala website). For a professional it's just extremely annoying when a language tries hard to know better then they how "good code" should look like. The main thing about a expert programmer is that he knows when it's OK to break "rules". Needing to jump through arbitrary but completely useless loops just to do that — when you know exactly what you're doing(!) — makes me mad sometimes.
I considered to fork the compiler not only once because of this. I hate such kind of "but we know better" behavior.
Earlier quoted context omitted.
> My favorite is uniform function call syntax. In several languages (Nim, Koka, D, …), you can always write bar.foo(baz) instead of foo(bar, baz) and vice-versa. To me, these are "Tell bar's foo to do something with baz." and "Tell foo to do something with bar and baz.". So being 'able' to flipflop the syntax is at least temporarily semantic'ly confusing.
The main selling point is the ability to chain calls foo.do_this(bar).do_that(baz) instead of do_that(do_this(foo, bar), baz)
do_this(foo, bar) |> do_that(baz)
do_this(foo, bar) | do_that(, baz)
Earlier quoted context omitted.
I think it's okay for a language to help guide its users toward "better code" (of course Rust is the big one for this). But I'm also a firm believer of providing escape hatches. So it should be just a toggle in the project/file/directory to enable whatever behavior. And a very good language would require a human readable explanation for these, so when the developer says allowEmojisInCode = true "we decided to allow e…
Scala has this escape hatch. But it's annoying. Why can I use arbitrary symbols (even with spaces, and such) by adding back-ticks, but not regularly. It wouldn't make any difference, besides not looking bad and needing extra key strokes for absolutely no gain (as it does not prevent bad code anyway!). I hate that kind of hand holding! Like I said: It's not the business of a language to judge what kind of code is "goo…
> It's not the business of a language to judge what kind of code is "good".
Well, yes, but no. Language design is just inseparably infused with judgement calls. Making things easy leads to them being used (as the backtick illustrates, making things hard reduces their usage, even if it sounds nice that it allows for special cases).
But as you imply the language has to be flexible and thus powerful enough to provide the option of a seriously different design trade off. (Because backticks are just a bad compromise. It's not really switching to a different design choice after all.)
> I hate such kind of "but we know better" behavior.
I think that implies too much intent on the Scala core team, unfortunately the reality is - probably - that historically someone wanted something, it got done somehow, and that's it. (In the particular case of backticks maybe Martin really had a strong opinion. Dunno. Probably you have looked into this at least a few times if you considered a fork :) )
... related to this the recent discussion about Rust's GAT (generic associated trait) feature is a very interesting case study in the intersection of language design, "project governance/management" (the reality of pragmatic compromises). There a small team spent at least a year developing GAT support for the compiler, and then a bunch of people were asked to decide whether to merge it. And it's a very unenviable position, because of course the work was not perfect. So what to do? In the end, I think at least, the narrative that was comfortable for everyone involved was that "this is the best version we can have realistically, and yes it provides net positive value in this current state".
https://github.com/rust-lang/rust/pull/96709#issuecomment-12...
My favorite is uniform function call syntax. In several languages (Nim, Koka, D, …), you can always write bar.foo(baz) instead of foo(bar, baz) and vice-versa. Another one from Nim is the implicit result variable. Instead of having to do this: func sum(nums: seq[int]): int = var result = 0 for num in nums: result += num return result you just do this: func sum(nums: seq[int]): int = for num in nums: result += num It…
> My favorite is uniform function call syntax. In several languages (Nim, Koka, D, …), you can always write bar.foo(baz) instead of foo(bar, baz) and vice-versa. To me, these are "Tell bar's foo to do something with baz." and "Tell foo to do something with bar and baz.". So being 'able' to flipflop the syntax is at least temporarily semantic'ly confusing.
E.g. in D to convert between different types you can use std.conv:
import std.conv;
"123".to!int;
123.to!string;
to!int("123")
to!string(123)
SDL_CreateRenderer(window, -1, 0);
window.SDL_CreateRenderer(-1, 0);
void CreateRendererAndInitialize(SDL_Window* window){}
window.CreateRendererAndInitialize();