It used to be issue - in your local network, you had IPv6 automatically with Vista and newer (the same for Linux distributions). So your browser resolved AAAA records, trued o open connection to the the host, after few seconds found out that it is going nowhere, resolved the A records, the site worked.
So it became popular to manually disable IPv6 to speed up the browsing.
I no longer remember which version it was and don't feel like going through those lists now, but I remember one of those versions changed some JDBC interfaces which would break any application using JDBC.
Well, it kinda depends on exactly what the breaking changes are and how much code they break, don't you think? Certainly none of the languages you mention in the grandparent comment broke Hello, world. It's also a question of what share of issues can be automatically flagged and when (build, run?)
Python had its share of breaking changes as well over the years and there wasn't much fuss about them. Who refused to upgrade over class name(object) or say hex(-1) producing '-0x1' instead of '0xffffffff'?
Yeah, you should have. An application is not supposed to implement JDBC. The database driver is supposed to implemented JDBC. If your application implements JDBC you're doing it wrong.
Just like nobody walks around and complains that new versions of the servlet API break any Java web application because web applications are not supposed to implement the servlet API. That's the job of the server.
Yeah, but not your application. If the driver specification gets updated it's not really surprising that the drivers will need to be updated. But the same is true for every specification. However your application doesn't need to be changed.
Those drivers can be application specific, as it was the case in the application I had to fix. Why it was made so, will be kept under the covers of the NDA agreement.
Another use case, many developers mock JDBC by creating their own dummy drivers, specially in large companies where mocking libraries are frown upon.
So we went from "would break any application using JDBC" to large company rolling their own database drivers for reasons that can't be disclosed (probably to protect the guilty).
> as it was the case in the application I had to fix. Why it was made so, will be kept under the covers of the NDA agreement.
Standard case of a large company doing it wrong and blaming somebody else when it comes back to bite them rather than fixing it. And hiding behind an NDA. Seriously what was the expectation? That JDBC never changes? Because at that time JDBC was already at version 3.0 which is obviously the final version after which no features would ever be added again.
> Another use case, many developers mock JDBC by creating their own dummy drivers, specially in large companies where mocking libraries are frown upon.
If you're doing it wrong then you're doing it wrong. Nobody to blame but yourself. Just because you're a large company doesn't make it right. Part of why it's wrong is that it will come back and bite you later on. And that's the problem in this case? The compiler tells you where you need to implement which methods.
Two give you two other examples. Interfaces for HTTP likely need to be updated when something in HTTP changes (WebSockets, HTTP/2). Servers implementing this will need to be updated to implement this. You don't accuse the language of the web server to make a breaking change. That's just how these things work. Same for SSL/TLS features like SNI. Sure it could be that you absolutely have to run your own web server or SSL/TLS implementations for reasons that you can't disclose because you're under an NDA. But then you expect that you'll have to maintain them and add additional features, don't you?
Maybe you just don't like traveling. There are lots of stories about traveling digital nomads on HN. That type of life never sounded interesting to me. Maybe you just don't like it either.
I've thought about starting my own company, but I don't want to start a startup. I want to start a company without investors that actually makes money from the beginning.
Although it is something I think about from time to time, I am sticking to the job I have for a while. I learn a lot on the job and it's a nice place to work.
public final class Article{
public final String title;
public final String author;
public final List<String> tags;
public Article(String title, String author, List<String> tags) {
this.title = title;
this.author = author;
this.tags = tags;
}
}
Getters don't seem very useful on an immutable object.
If you ever want to change the implementation of Article, you'd break anyone that was using that part of your API. If you use getters, you can change your implementation without breaking the consumers of your API.
For instance, let's say that you don't want to store the author's name as a string anymore, and want to store a reference to an Author object. If you have a getAuthor() method, you can change it from a simple getter to instead call author.getName(), preserving your public-facing API.
And this is one of the major reasons why Java is regarded as verbose. There's a simple solution (have the compiler transparently rewrite references to x.foo to x.getFoo / x.setFoo and transparently add getFoo/setFoo - the JVM inlines (trivial) getters and setters anyways) and yet Java, in the interests of "transparency", doesn't allow it.
And their justification fails. Sure, currently if you read x.foo you know that no code is being executed - but you never see x.foo because everything has getters and setters. So all it does in practice is make things (even) more verbose.
> If you ever want to change the implementation of Article, you'd break anyone that was using that part of your API. If you use getters, you can change your implementation without breaking the consumers of your API.
Then it wouldn't be immutable, if I can change the implementation I can also create a mutable version.
Edit example
public class Article {
private final String title;
private final String author;
private final List<String> tags;
private Article(String title, String author, List<String> tags) {
this.title = title;
this.author = author;
this.tags = tags;
}
public String getTitle() {
return title;
}
public String getAuthor() {
return author;
}
public List<String> getTags() {
return tags;
}
}
public class MutableArticle extends Article {
private String title;
private String author;
private List<String> tags;
public MutableArticle() {
super(null, null, null);
}
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
public String getAuthor() {
return author;
}
public void setAuthor(String author) {
this.author = author;
}
public List<String> getTags() {
return tags;
}
public void setTags(List<String> tags) {
this.tags = tags;
}
}
Making a class immutable doesn't mean that the implementation is fixed. If you need to change your implementation to store data differently, the consumers of your API shouldn't need to be modified. The following modification to your first class would still be immutable:
public class Article {
private final Author author;
...
public String getAuthor() {
return author.getName();
}
}
Also, your first class isn't fully immutable—getTags should be implemented as follows:
/**
* @return Unmodifiable list of tags
*/
public List<String> getTags() {
return Collections.unmodifiableList(tags);
}
> Also, your first class isn't fully immutable—getTags should be implemented as follows:
True. It would be nice if Java had some immutable collection classes that don't have mutable methods. A method that gets a List<String> made with Collections.unmodifiableList(tags), doesn't know that it is actually immutable.
For some reason seeing your code really bothers me. Is it normal to ever use private variables in inheritance like that?
Say you had toString() in Article class that returned ("%s%" author, title).
Now if you create a MutableArticle on it, ma.toString() will return null unless you override toString on it as well (since Articles variables are private and not inherited).
I don't code much so I don't know is it normal to see code like that?
Also less relevant but Articles constructor should probably be public?
I agree that this design is sub-optimal. However, if a.toString() called the getters instead of using the instance variables directly, you wouldn't have problems.
The Article class is unusable as provided due to the private constructor (in fact, the MutableArticle class wouldn't even compile), but private constructors can be useful. I often use private constructors and instead provide public static methods that call the constructors. This practice is often derided, and goes into Java's perception as a verbose, arcane language, but it allows for improving an API without breaking clients built to previous versions, as well as making an API more clear (since we can give the static methods more descriptive names).
Thanks for taking time to reply. Didn't think about having toString use the getters instead of accessing the instances directly. I guess in some way that's the more proper way of doing it in the context of OOP.
I'm familiar with Java private constructors and builders/factory methods though, that was more of a minor nitpick, but again thanks for explaining on that.
So I think a fair question at this point is how often does that happen? To further inquire, how often does that happen in contexts that you don't control?
I'm sure that library/framework people need to worry about that. Most normal developers do not. For many cases Java objects like Article are just structs. They are static maps. Sure, in the example on the site there was a getTags that added some logic, but still, pretty much a struct.
Switching to either public accessor for mutable or immutable objects actually will stream line code. You might say that public mutators are bad; encapsulation and all that. For the most part little is actually gained in the majority of getter/setter code to necessitate their weight.
Heck, as per the JavaBean spec (a spec for making components to create drag and drop UIs by the way), you can't even have fluent APIs where the setter returns "this". It has to be void.
API stability has value. If you're a library, you probably want to do this just to be safe. But really for most imperative Java code it's just a lot of fluff for little value.
That's also one of the differences between Scala and Java. In Scala you have referential transparency, so you easily can switch between fields/properties and methods without changing the calling code.
Punishment also works on cats. You just have to be very consistent when applying it (this is exactly the same for dogs). If you punish your cat(or dog) you have to do it immediately. If the cat is done scratching its nails, and you squirt water, you are too late.
[Edit] Changed negative reinforcement to punishment, rbehrends was correct when he pointed out that negative reinforcement is something different.
You should also learn a server side programming language with good performance(Java, C#, Go). I think Java is the best because it is mature, multi platform and you can also use it for Android programming.
Most open source/free software(free as in liberty) is free as in beer. It gets payed for by donations and/or big sponsors. It has no hidden costs. Not everything is available as open source/free software, but it is enough have a usable computer and even some games.
The difference is that such software goes through multi-year evolution and usage (be it bash or OpenOffice or kernel) so it makes sense for a company to invest on feature X that's missing for them, and get everything else for free.
On the other hand, in the game market, most games are a one-off experience with a very short lifetime (excluding MMO games). So there is no way they could be constructed through subsequent donations and evolutions.
Add to this the fact that open source communities are only made of programmers (because they are the ones benefiting most from the network effect and from incremental integration of software components), while games require other kind of professionals. Eg: volunteer designers in OSS world are mostly non existent; most of them are on the payroll of some sponsor.
That such a thing is possible. If I try to get below my limit in the Netherlands I am simply not able to. The only services who can go below my limit are my rent and gas/water/electricity bills. And then I just pay a high interest rate. Which doesn't really matter if you deposit money the next day.
