Which language is the least bad?
-
You just need to type two tiny words that will make trumpets sound from the heavens and liberate you from all of the wrongness and fuckups. They are:
import clr;
-
Yes, Haskell strings aren't so good. This is an artefact of the Haskell "Prelude" (the library included in the spec) focusing on
String
, which represents a list ofChar
s with their UTF-8 encoding, as opposed to a production quality data structure.The situation is getting a lot better.
Data.Text
became the recommended data structure, and the libraries target it now.
-
-
I think the trolling was a bit obvious there
-
@obeselymorbid Upvoting a six month old post. Y U DO DIS?
-
@another_sam said in Which language is the least bad?:
@obeselymorbid Upvoting a
sixthirty-one month old post. Y U DO DIS?FTFY
-
@obeselymorbid Holy shit I didn't notice the year this post was nearly THREE YEARS OLD WTF DUDE?
-
@another_sam The real WTF though is you having all the like notifications enabled.
-
@cartman82 said in Which language is the least bad?:
Yup, the answer to this is simple: C#
The only question is can you go Microsoft or does it have to be *nix.You actually did believe that at some point? You weren't always batshit crazy?!
-
@obeselymorbid said in Which language is the least bad?:
@another_sam The real WTF though is you having all the like notifications enabled.
I don't get very many and they expire when I don't log in so it's not a problem.
-
@another_sam said in Which language is the least bad?:
@obeselymorbid Upvoting a six month old post. Y U DO DIS?
You have met @obeselymorbid, yes?
-
@another_sam said in Which language is the least bad?:
@obeselymorbid Holy shit I didn't notice the year this post was nearly THREE YEARS OLD WTF DUDE?
@obeselymorbid is the @whargarbl of necrolikes.
-
@kt_ said in Which language is the least bad?:
You actually did believe that at some point? You weren't always batshit crazy?!
C# is still probably the best language (with Swift and Kotlin being its most serious competition). It's the MS ecosystem that's falling apart.
-
@yamikuronue said in Which language is the least bad?:
shudder at the idea that they might need to declare getters and setters instead of making everything public all the time.
There aren't convincing arguments for getters and setters if you're not writing a library for third parties to use. It's a classic cargo cult bullshit.
-
@wharrgarbl said in Which language is the least bad?:
@yamikuronue said in Which language is the least bad?:
shudder at the idea that they might need to declare getters and setters instead of making everything public all the time.
There aren't convincing arguments for getters and setters if you're not writing a library for third parties to use. It's a classic cargo cult bullshit.
So anybody can just modify your data? What if your data keeps changing and you don't know who keeps changing it?
One of the best reasons for having getters/setters is that you can put a breakpoint in there and see who's calling it.
-
@dangeruss said in Which language is the least bad?:
One of the best reasons for having getters/setters is that you can put a breakpoint in there and see who's calling it.
Another good reason is it makes it trivial to create immutable objects (public
get
, privateset
).
-
@raceprouk said in Which language is the least bad?:
@dangeruss said in Which language is the least bad?:
One of the best reasons for having getters/setters is that you can put a breakpoint in there and see who's calling it.
Another good reason is it makes it trivial to create immutable objects (public
get
, privateset
).Another is, it's easily extendable, if you need additional behavior.
-
@cartman82 said in Which language is the least bad?:
Kotlin
No @cartman82, ketchup is not a programming language.
https://maspex.com/files/pl/product_image/main/file_55af856fc92660916207446.png
-
@dangeruss said in Which language is the least bad?:
@wharrgarbl said in Which language is the least bad?:
@yamikuronue said in Which language is the least bad?:
shudder at the idea that they might need to declare getters and setters instead of making everything public all the time.
There aren't convincing arguments for getters and setters if you're not writing a library for third parties to use. It's a classic cargo cult bullshit.
So anybody can just modify your data? What if your data keeps changing and you don't know who keeps changing it?
I have no idea what you're talking about. *goes back to coding in Rust*
-
@gąska said in Which language is the least bad?:
I have no idea what you're talking about. *goes back to coding in Rust*
I have the antidote to Rust.
-
@dangeruss said in Which language is the least bad?:
One of the best reasons for having getters/setters is that you can put a breakpoint in there and see who's calling it.
In a good language, you can just refactor to add a getter if and when you actually need to put a debugger there.
-
@dangeruss said in Which language is the least bad?:
So anybody can just modify your data? What if your data keeps changing and you don't know who keeps changing it?
One of the best reasons for having getters/setters is that you can put a breakpoint in there and see who's calling it.
It was Kevin from Accounting, the bastard!
Don't you mean what is calling it? Or did you accidentally unleash Skynet?
-
@rhywden Kevin from Accounting is Skynet?
That explains a lot actually…
-
@gąska said in Which language is the least bad?:
@dangeruss said in Which language is the least bad?:
@wharrgarbl said in Which language is the least bad?:
@yamikuronue said in Which language is the least bad?:
shudder at the idea that they might need to declare getters and setters instead of making everything public all the time.
There aren't convincing arguments for getters and setters if you're not writing a library for third parties to use. It's a classic cargo cult bullshit.
So anybody can just modify your data? What if your data keeps changing and you don't know who keeps changing it?
I have no idea what you're talking about. *goes back to coding in Rust*
When I started here, there's a strong belief in:
class CSomeClass : public CRefCount<CSomeClass> { public: CString m_thisString; int m_thatInt; void SomeFunc(); ... };
because why would we want to hide them...
edited to make it a refcounted class. because what is
shared_ptr
(ok, they were still on vs2005, so boost was required)
-
@wharrgarbl said in Which language is the least bad?:
There aren't convincing arguments for getters and setters if you're not writing a library for third parties to use.
Which language? .Net you may be right, Java you're dead wrong because refactoring. Different answers for other languages.
-
@another_sam said in Which language is the least bad?:
@wharrgarbl said in Which language is the least bad?:
There aren't convincing arguments for getters and setters if you're not writing a library for third parties to use.
Which language? .Net you may be right, Java you're dead wrong because refactoring. Different answers for other languages.
No, with Java I can easily refactor a public attribute into a getter and setter in the very rare case it's needed after the fact. And by very rare I mean maybe once a decade.
-
@wharrgarbl said in Which language is the least bad?:
No, with Java I can easily refactor a public attribute into a getter and setter in the very rare case it's needed after the fact. And by very rare I mean maybe once a decade.
Right; nobody's saying "it should never be done", it's more "don't do it until you actually need to for some reason". Unless your language sucks, you can change your public properties into getters/setters without breaking any other code.
The same applies to making interfaces for your classes, BTW.
-
@blakeyrat said in Which language is the least bad?:
nobody's saying "it should never be done",
They are. Zombie cargo cultists that follow arbitrary rules they don't understand are everywhere, and I've seen my share of them.
-
@wharrgarbl said in Which language is the least bad?:
No, with Java I can easily refactor a public attribute into a getter and setter in the very rare case it's needed after the fact. And by very rare I mean maybe once a decade.
public class Foo { public String bar; } ... Foo.bar="Fubar!";
does not "easily" refactor into
public class Foo { private String bar; public void setBar(String bar) ... public String getBar() ... }
because
Foo.bar="Fubar!";
is now a syntax error...
-
@sloosecannon said in Which language is the least bad?:
@wharrgarbl said in Which language is the least bad?:
No, with Java I can easily refactor a public attribute into a getter and setter in the very rare case it's needed after the fact. And by very rare I mean maybe once a decade.
public class Foo { public String bar; } ... Foo.bar="Fubar!";
does not "easily" refactor into
public class Foo { private String bar; public void setBar(String bar) ... public String getBar() ... }
because
Foo.bar="Fubar!";
is now a syntax error...
Also, it takes all of 3 seconds to generate getters and setters in a good IDE. So you're saving no time at all...
-
@sloosecannon said in Which language is the least bad?:
does not "easily" refactor into
Eclipse does easily refactor that.
-
There are no bad languages, just bad coders. Even ES6 can be turned into a modern masterpiece using the right people. Some languages might enforce more care (e.g. hard typing), though not only can that usually be circumvented (e.g. stringly typed), but anyone careless won't do much other than trying to shut up the compiler's warnings. But I'd personally say C# due to it's popularity and support, as well as being a Java-like language.
-
@sloosecannon said in Which language is the least bad?:
Also, it takes all of 3 seconds to generate getters and setters in a good IDE. So you're saving no time at all...
It makes my code uglier, and I hate stupidity with a passion.
-
@wharrgarbl said in Which language is the least bad?:
@sloosecannon said in Which language is the least bad?:
does not "easily" refactor into
Eclipse does easily refactor that.
Cool.
IntelliJ probably does too.
But there's still no reason to make everything public. Generating getters and setters is like IDE 101. And you get the added benefit of not having weird random shit happen when people change your data.
If you're OK with that, I'm not sure what to tell you.But getters and setters are pretty much in the basics of "good programming".
-
@wharrgarbl said in Which language is the least bad?:
@sloosecannon said in Which language is the least bad?:
Also, it takes all of 3 seconds to generate getters and setters in a good IDE. So you're saving no time at all...
It makes my code uglier, and I hate stupidity with a passion.
It really doesn't, and I don't see what stupidity has to do with this. Unless we're talking about the stupidity of having public member variables.
-
@sloosecannon said in Which language is the least bad?:
But getters and setters are pretty much in the basics of "good programming".
And you think you get to decide what is "good programming".
-
@wharrgarbl said in Which language is the least bad?:
@sloosecannon said in Which language is the least bad?:
But getters and setters are pretty much in the basics of "good programming".
And you think you get to decide what is "good programming".
Nope
-
@sloosecannon well, I only accept something as a good practice if it demonstrably prevent more effort than it costs. So far in 20 years of programming I never needed to put logic in a getter or setter after the fact.
-
@wharrgarbl said in Which language is the least bad?:
@sloosecannon well, I only accept something as a good practice if it demonstrably prevent more effort than it costs. So far in 20 years of programming I never needed to put logic in a getter or setter after the fact.
And @SpectateSwamp has never needed to do anything other than global variables in more than 20 years of programming. Doesn't mean it's good practice...
-
@sloosecannon said in Which language is the least bad?:
Also, it takes all of 3 seconds to generate getters and setters in a good IDE.
And now you've got to search through all your codebase to find where you need to update all the uses of the field to be switched to using the methods. That's the real cost, not the cost of changing the class itself. Actually, I don't know how C# generates field accesses at IL level; do properties use the same bytecodes — with binding to what's actually going on at the low-level being a runtime thing— or would switching things around force a rebuild?
-
@dkf said in Which language is the least bad?:
@sloosecannon said in Which language is the least bad?:
Also, it takes all of 3 seconds to generate getters and setters in a good IDE.
And now you've got to search through all your codebase to find where you need to update all the uses of the field to be switched to using the methods. That's the real cost, not the cost of changing the class itself. Actually, I don't know how C# generates field accesses at IL level; do properties use the same bytecodes — with binding to what's actually going on at the low-level being a runtime thing— or would switching things around force a rebuild?
Oh, no I'm taking about generating them on creation, not during refactoring. That's insane :)
-
-
@blakeyrat said in Which language is the least bad?:
you can change your public properties into getters/setters
In Java, by convention, "public property" means matching getters/setters. Public mutable fields aren't really a thing except apparently in @wharrgarbl's code. But you also said:
@blakeyrat said in Which language is the least bad?:
Unless your language sucks
Java does suck. But then so does every other language I've ever tried. Current fad: Kotlin.
-
@another_sam said in Which language is the least bad?:
Kotlin
Feels a lot like C#. Or C#ish. Trying to modernize Java. I'd rate it better than Java, but not as good as C#...
-
@dkf said in Which language is the least bad?:
And now you've got to search through all your codebase to find where you need to update all the uses of the field to be switched to using the methods. That's the real cost, not the cost of changing the class itself.
You multiply the cost by the probability to calculate a risk. In this case the probability is astronomically low, and the cost is low. Also, eclipse does that automatically IIRC.
-
@dkf said in Which language is the least bad?:
@sloosecannon said in Which language is the least bad?:
Also, it takes all of 3 seconds to generate getters and setters in a good IDE.
And now you've got to search through all your codebase to find where you need to update all the uses of the field to be switched to using the methods. That's the real cost, not the cost of changing the class itself. Actually, I don't know how C# generates field accesses at IL level; do properties use the same bytecodes — with binding to what's actually going on at the low-level being a runtime thing— or would switching things around force a rebuild?
I am fairly certain that, in IL, there is no distinction between a simple set;get; property and a field in the current compiler.
If Intellisense complains about a missing property and you tell VS2017 to generate it, it uses field syntax.
-
@sloosecannon said in Which language is the least bad?:
And @SpectateSwamp has never needed to do anything other than global variables in more than 20 years of programming. Doesn't mean it's good practice...
Global variables have real observable problems that happen frequently. It's not comparable.
I don't accept bullshit nor fads, and I have a low opinion on people that push that without real and pragmatic arguments. That means most Java programmers. Dunno how a single language attract so many morons.
-
@dkf said in Which language is the least bad?:
do properties use the same bytecodes — with binding to what's actually going on at the low-level being a runtime thing— or would switching things around force a rebuild?
Field access is completely different than method calls, and properties are just special-named getter and setter methods (as in they literally have the specialname flag set), so you have all the ABI pain of Java in that regard. Fortunately, at the API level, all you need to do is rebuild; there's no syntax difference between field access and property access in most CLR languages, so as soon as the compiler notices the changed metadata you're good to go.
Or, you know, you could start out with
prop
Tab or C# autoproperties rather than field access in the first place, because other than P/Invoke structs why on earth would you have nonprivate fields?!
-
@wharrgarbl said in Which language is the least bad?:
It's not comparable.
Uh, yes they actually are...
@wharrgarbl said in Which language is the least bad?:
so many morons.
Perhaps they're not the problem...
-
@twelvebaud said in Which language is the least bad?:
Or, you know, you could start out with propTab or C# autoproperties rather than field access in the first place, because other than P/Invoke structs why on earth would you have nonprivate fields?!
struct Point { int x; int y; }