IDEs still suck at file management
-
Someone else stuck on 1.4!
Yeah, but only for 2 more weeks. Then we move to Android. But don't worry, I'm sure it will be just as awful!
-
At least you'll be able to use a newer version of Java, one with generics and other useful features like that
-
one with generics
The vendor of the stuff we run on 1.4 rolled their own version of generics, rather than just supporting Java 1.5.
They work as well as you're imagining they do.
-
They work as well as you're imagining they do.
I'm imagining the contents of that truck from Back To The Future, the one Biff and his mates crash into after chasing McFly thirty seconds after he invents the skateboard.
-
I know that they are technically not IDEs, but just to throw this in:
Both Sublime Text and Atom are perfectly capable of creating new files, creating new directories, renaming, and moving stuff around.
Delete? HAH! Oh, they will pop up a "Are you sure" dialog, but actually deleting stuff, nope, too much work.
-
Both Sublime Text and Atom are perfectly capable of creating new files
They'd be pretty awful text editors if they couldn't.
-
I know that they are technically not IDEs, but just to throw this in:
Both Sublime Text and Atom are perfectly capable of creating new files, creating new directories, renaming, and moving stuff around.
Well, duh - as you noted, they're not IDEs.
-
I moved to NetBeans from Eclipse.
I tried both for C++ development on Windows, and decided to stick with NetBeans because I prefer its project properties dialog. It's not great but I've gotten used to how it works. And it produces makefiles, so I can build the project elsewhere without needing the IDE.It makes a lot of sense but the language that mandates it is "totally and utterly retarded"?
Mandating something that makes sense is stupid because you'll eventually find a situation where the thing that normally makes sense is a hindrance, and then you have to find ways around it. If it makes sense, people will naturally gravitate to doing it that way in the first place. No need to mandate it.
-
Mandating something that makes sense is stupid
I see.
If it makes sense, people will naturally gravitate to doing it that way in the first place.
So the whole thing is
-
-
IntelliJ
It is really, really good. Fuck Eclipse and NetBeans and all that shit. IntelliJ works well - it has some foibles - but it is a very good IDE
-
I tried both for C++ development on Windows, and decided to stick with NetBeans
Why not Visual Studio?Edit:
-
Why not Visual Studio?
VS tends to lag when it comes to implementing new language features, they have sometimes implemented them oddly, and relies a bit too much on their own extensions. Plus, by using the Windows gcc implementation (mingw), I know it'll mostly compile correctly on *nix, after switching any system calls.
That said, if I have to do something specifically for Windows that uses MFC or ATL, I do use it. At work, for example, I use VS. And the debugger and intellisense are better than what gcc and NetBeans offer. But if I'm making something like a game, or a service, script, console app or whatever that isn't intended to use Window's visual themes, I prefer gcc (with NetBeans on top).
-
This is by far the most common reason I make an inner class. The hipsters will come and tell me about how they pass lambdas or some bullshit, but I tend to make separate, named functions in javascript, too.
You can give javac a bunch of arbitrarily named .java files on the command line and it will compile all classes in them no matter what they are called.
Section 7.2 of the JLS says that the compiler may enforce the top-level-class-in-compilation-unit-named-after-itself restriction. The one from Oracle does. So unless you're using IcedTea or some other crap, you're wrong.
-
Hm, I have certainly compiled sources outside the in/sa/ne/ly/nes/ted directory structure and I am rather sure I've seen sources with more than one top-level class in them, but it's true there always was one with the same name as the file.
-
You can have more that one top-level class in the file, but if it's public or you reference it from any other compilation unit, the compiler errors out if the name doesn't match.
-
VS tends to lag when it comes to implementing new language features
According to this, currently it's pretty on par with other compilers. Also, it already has (experimental) support for modules.they have sometimes implemented them oddly, and relies a bit too much on their own extensions
For the most part, it's not a problem. It's just that some code that doesn't compile on GCC, compiles on MSVC, and that some library functions have very minor differences in behavior.But whatever floats your boat.
-
Because Windows doesn't have a way to force-unlock a file
Yes it does, it's the same tool that fixes 99% of Windows problems. It's called "Reboot"
-
Most dynamic languages do care, because they need to be able to find them given the import statement.
With Go's default build tools, filenames can be used to designate a file as containing test cases (
foo_test.go) or being for a specific OS/arch (bar_windows.go,baz_darwin_arm.go)
-
Conditional compilation based on filename? Wow, being Go programmer sucks.
-
According to this, currently it's pretty on par with other compilers.
Yes, they have over time become better about following the standard. I got used to my current setup several years ago, however, and now I don't have an incentive to switch.
With Go's default build tools, filenames can be used to designate a file as containing test cases (foo_test.go) or being for a specific OS/arch (bar_windows.go, baz_darwin_arm.go)
So instead of a sane build tool, they use file names as part of the build configuration? Yuck.
-
There are ~15 different ways (one for each data field in object). Which gives me 15 different comparison functions. They're all one-liners. Do you really think creating 15 5-line files would be more readable than having anonymous classes?
Of course, the best solution would be lambdas, but Java 1.4 doesn't have lambdas.
Sometimes it feels like I'm the only person who thinks that yes, having 15 different 5-line classes (not necessarily all in their own file, though) is more readable. Of course, my point of view is probably skewed by the number of times I've had to read someone else's code that has anonymous inner classes and/or lambdas that are 50+ lines long and 5 layers deep.
-
Sometimes it feels like I'm the only person who thinks that yes, having 15 different 5-line classes (not necessarily all in their own file, though) is more readable.
You missed the point - I was talking specifically about having them in their own files. 5-line classes wasn't the point - 5-line files was. It's stupid to have 15 5-line files, whether there are any classes or not. Unless it's to make C++ compile faster. Then it makes sense. But only if it really compiles faster.In themselves, short classes are totally fine, even preferable. But not every such short class deserves to be named. Especially that they either end up in named variable anyway, or they don't live long enough to matter.
Of course, my point of view is probably skewed by the number of times I've had to read someone else's code that has anonymous inner classes and/or lambdas that are 50+ lines long and 5 layers deep.
Your experience with 50+ lines long anonymous classes doesn't necessarily map well to one-liner anonymous classes.
-
Your experience with 50+ lines long anonymous classes doesn't necessarily map well to one-liner anonymous classes.
I suspect he's having the same problem I'm having at the moment.
-
Sometimes it feels like I'm the only person who thinks that yes, having 15 different 5-line classes (not necessarily all in their own file, though) is more readable.
-
@TwelveBaud said in IDEs still suck at file management:
You can have more that one top-level class in the file, but if it's public or you reference it from any other compilation unit, the compiler errors out if the name doesn't match.
The
publicmatters (and that's largely a sane restriction). For non-public classes, you're usually fine slapping them all together in the same file since the only sane way to run a Java compiler is to recompile all the classes every time. (Fortunately, javac is pretty fast since it isn't optimising and can target bytecode instead of needing to issue machine code. The complicated stuff happens elsewhere.) Indeed, it's this complexity which is why you never want to usemakewith Java.The main reason for the source filename restriction IIRC is so that the compiler can find the code if it automagically decides it wants to (re)compile it anyway. The compiler is really bad at making that decision; relying on it leads to pain. Rebuild it all at once; on modern hardware it only adds a few seconds even for a lot of source files. (OTOH, you don't need to rebuild across JAR boundaries.)
-
@RaceProUK said in IDEs still suck at file management:
Are you writing 100 line lamdas?
In C#, no; they tend to be one-liners, usually things likevar booking = ctx.Bookings.FirstOrDefault(b => b.BookingId == bid);where the LINQ query comprehension syntax would be overkill.
In JavaScript though, I do write longer ones (where I can; it's an ES6 feature after all), simply because
someFunction(arg1, arg2, (success) => { if (success) { alert('yay!'); } else { alert('aww!'); } });looks cleaner to me than
someFunction(arg1, arg2, function (success) { if (success) { alert('yay!'); } else { alert('aww!'); } });We're in the process of moving from Actionscript to Typescript/Javascript, and so I'm being exposed to the arrow syntax. Visually, I find that it makes it harder to see what's going on, because the => operator blends into the background more than the function keyword. Maybe the IDE can be configured to emphasize it more - I'll have to look into that.
Since I prefer separate named functions, that shouldn't be a problem for me, except for one nasty difference between the two (in TS anyway - I don't know if it's true in JS as well). The arrow syntax retains scope, while the function keyword doesn't. In @RaceProUK 's first example, this would refer to the definer of someFunction, while in the second example, this would refer to the caller of the arrow lambda thingie. That bit me hard the first time I tried the function keyword or a separate function.
Luckily, a function in TS or JS is an object with a bind() method, so you can say function(success) { ... }.bind(this), thereby setting the scope of that function to the value of this at the time of the bind() call, i.e. the definer of someFunction, solving the problem.
But if you don't know about this difference and the solution, you can get in trouble by thinking the arrow and the function keyword are interchangeable.
-
@boomzilla said in IDEs still suck at file management:
I have a functionality of sorting complex objects in several ways.
This is by far the most common reason I make an inner class. The hipsters will come and tell me about how they pass lambdas or some bullshit, but I tend to make separate, named functions in javascript, too.
In Actionscript (which we are thankfully moving away from), we don't even have the option of inner classes, and callback functions are rampant because RPC's are always asynchronous. Like you, I prefer separate, named functions over anonymous inline functions. They're easier to debug, reuse, and refactor.
-
@aliceif said in IDEs still suck at file management:
Why not something like
someFunction(arg1, arg2, (success) => alert(success ? 'yay!', 'aww') );?
Since you already stole my thunder, I'll just add that you don't actually need parentheses around the argument list if it's exactly 1 argument.
someFunction(arg1, arg2, success => alert(success ? 'yay!' : 'aww'));@RobFreundlich said in IDEs still suck at file management:
We're in the process of moving from Actionscript to Typescript/Javascript, and so I'm being exposed to the arrow syntax. Visually, I find that it makes it harder to see what's going on, because the => operator blends into the background more than the function keyword.
The arrow syntax retains scope, while the function keyword doesn't.
That's the point, though. A function stands out because it creates a new scope. The arrow syntax blends in because it doesn't. It does look different, but I got used to it pretty quickly.
In @RaceProUK 's first example, this would refer to the definer of someFunction, while in the second example, this would refer to the caller of the arrow lambda thingie. That bit me hard the first time I tried the function keyword or a separate function. ... you can get in trouble by thinking the arrow and the function keyword are interchangeable.
Yes. That is true.
-
@anotherusername said in IDEs still suck at file management:
I'll just add that you don't actually need parentheses around the argument list if it's exactly 1 argument.
twitch
put the damn parens in!
gawd i bet you're one of those people who think that it's a good idea to omit the braces when "it's just one line". fick it, put the braces in. stop destroying the visual cues that you can use to help navigate around your code!
GAH!
RAGH!
RRRRRRGH!
-
@accalia said in IDEs still suck at file management:
gawd i bet you're one of those people who think that it's a good idea to omit the braces when "it's just one line".
Yep.
With the amount of code samples I've posted on here, I'd have thought you'd have known that by now.
-
@anotherusername said in IDEs still suck at file management:
@accalia said in IDEs still suck at file management:
gawd i bet you're one of those people who think that it's a good idea to omit the braces when "it's just one line".
Yep.
With the amount of code samples I've posted on here, I'd have thought you'd have known that by now.
/me stomps off in a rage, ranting about why braces should never be omitted to anyone in earshot and who isn't already fleeing in panic
-
@loopback0 said in IDEs still suck at file management:
totally and utterly retarded, the filename must match the class name
The only OO language I've really used is Java so it's just normal for me but I don't see why you wouldn't do that anyway?
Just to start off with one obvious reason: what if you have a non-retarded language that allows you to put more than one class in the same file because they logically belong together? Which class should the file be named after?
@kt_ said in IDEs still suck at file management:
giving money to the poor is good
Giving money to the poor is a terrible, terrible idea!
"When I give food to the poor, they call me a saint. When I ask why the poor have no food, they call me a communist."
-- Archbishop Hélder Câmara
-
@masonwheeler said in IDEs still suck at file management:
Which class should the file be named after?
-
@accalia said in IDEs still suck at file management:
gawd i bet you're one of those people who think that it's a good idea to omit the braces when "it's just one line"
Or the kind of person who writes
.then((foo) => bar())instead of.then((foo) => { return bar()})
-
@accalia said in IDEs still suck at file management:
omit the braces when "it's just one line"
I'm never really sure what I should do when the body of the if statement is just a single keyword, especially in C++ where it's customary to match braces' horizontal positions.
if (some_condition) { break; }It just seems like a waste to do it this way when it would be one line in Python, Ruby, or Perl.
-
@ben_lubar I'll omit the braces when it's a single statement.
-
@fbmac said in IDEs still suck at file management:
I'll omit the braces when it's a single statement.
Isn't that the only time you can omit them?
-
@Tsaukpaetra I omit an infinite number of curly braces, because I could write things like:
void xxx() {{{{{
printf("foo");
}}}}}
-
@ben_lubar said in IDEs still suck at file management:
I'm never really sure what I should do when the body of the if statement
it's an if statement you fucking put the braces in.
same as you do for for loops, while loops, do while loops, switch statements, and methods!
-
@accalia said in IDEs still suck at file management:
while loops, do while loops
:gopher: what are those
-
@ben_lubar said in IDEs still suck at file management:
I'm never really sure what I should do when the body of the if statement is just a single keyword
This is basically how Apple fucked up a major chunk of their security. (That and not paying attention to warnings about unreachable code; those matter!) Put the braces in; you can afford the extra line or lines it takes, as there's no world shortage of whitespace.
@ben_lubar said in IDEs still suck at file management:
if (some_condition) { break; }OTOH, I don't like that style either. 1TBS for me…
-
same as you do for for loops
for (var c = op(0); someCond(c); c = op(c)) {}, while loops
while ((c = process(c)), cond(c)) {}, do while loops
do { var c = 0; } while ((c = process(c)), cond(c)), switch statements
val result = data match { case Extract(stuff) => stuff >>-|> 2 }Okay, you got me there - have an obscure operator I just made up
, and methods!
class Braceless { power = ups => next => action => critical => hit() }I added the braces - they don't seem to be making much of a difference.
-
@Yamikuronue said in IDEs still suck at file management:
@accalia said in IDEs still suck at file management:
gawd i bet you're one of those people who think that it's a good idea to omit the braces when "it's just one line"
Or the kind of person who writes
.then((foo) => bar())instead of.then((foo) => { return bar()})That's
.then(foo => bar()), if you don't mind.@accalia said in IDEs still suck at file management:
it's an if statement you fucking put the braces in.
No.
same as you do for for loops, while loops, do while loops
No.
switch statements
...well, you've got me there. But you can't omit them there; it's a syntax error. They're required there.
methods!
Depends. If it's a one-liner fat arrow function, no. If it's complex enough to require more than one line, then yeah... braces are required for that syntax.
-
@svieira said in IDEs still suck at file management:
>>-|>Seems fishy.
@Yamikuronue said in IDEs still suck at file management:
@accalia said in IDEs still suck at file management:
gawd i bet you're one of those people who think that it's a good idea to omit the braces when "it's just one line"
Or the kind of person who writes
.then((foo) => bar())instead of.then((foo) => { return bar()})Since you're not using
foo, might as well be.then(() => bar()). Or even.then(bar)IIRC.
-
@Dreikin
.then(() => bar())would work..then(bar)may or may not do the same thing, depending on whetherthenpasses any arguments to the callback function, and whetherbardoes something different if it's called with the arguments as it does if it's called without any arguments.
-
@anotherusername
for 
-
@accalia I don't put them in for any of those constructs unless they are necessary. If they are not they are omitted.
-
@accalia said in IDEs still suck at file management:
switch statements
O.o
And make it easy to forget a
break;?I mean, does the syntax even allow for that?
Or are we talking literally
switch?Can you even omit those??
/me is confused...
-
@sloosecannon said in IDEs still suck at file management:
And make it easy to forget a break;?
The real problem there is C-style fallthrough-by-default. Languages like Rust or C# don't have that.
The Codeless Code:
Case 214 Streams of Consciousness
