Slashdot Mirror
The IDE As a Bad Programming Language Enabler
theodp writes "When it comes to monolithic IDEs, Wille Faler has lost that loving feeling. In IDEs Are a Language Smell, Faler blogs about a Eureka! moment he had after years of using Eclipse for Java development. 'If the language is good enough,' Faler argues, 'an IDE is strictly not needed as long as you have good support for syntax highlighting and parens matching in the case of Clojure, or indentation in the case of Haskell.' So why do Java coders turn to Eclipse? 'Because [of] a combination of shortcomings in the Java compiler and Java's OO nature,' explains Faler, 'we end up with lots and lots of small files for every interface and class in our system. On any less than trivial Java system, development quickly turns into a game of code- and file-system navigation rather than programming and code editing. This nature of Java development requires IDEs to become navigation tools above all.' Yes, only an IDE could love AbstractSingletonProxyFactoryBean!"
I wrote a simple file system indexer at my last job. Enter part of a class name and it loads the source file in an editor. Eclipse failed because projects have to be small. This application had > 200 projects and any non-trivial tasks would have required working with 100 projects at a time.
http://michaelsmith.id.au
I prefer writing in a word processor why should software development in an IDE be any different. Refactoring, code, memory, and performance analysis... All good things. Ohh and that little thing called debugging.
/. Must have been hacked with this worthless article from a programmer that is still deciding between emacs and Eclipse.
Yo Willie, you can write shit code in any language, any IDE when you are a crappy programmer. IDEs help you better debug, code complete and refactor you crappy code.
I understand the train of thought, but I feel the conclusion is wrong. The correct conclusion is that OO design following accepted "best" practices (the SOLID principles) makes for difficult-to-navigate code. That doesn't necessarily mean that I think OO design is bad, it just has some pretty major downsides when it comes to navigability if you don't have good support from your development environment.
I remember reading somewhere about a system that does away with the concept of "files" entirely, and the whole coding process is based around smart navigation - what's on your screen could be pulled from many different locations at once without you having to know where from - shame I can't recall where I read that exactly.
He says that IDE usage is " 'Because of a combination of shortcomings in the Java compiler and Java's OO nature..."
I use an IDE because it has an visual debugger as I tend to develop aloways in debugging mode (see Hotspot dynamic class update and other JRebel features)...
But the guy must be a great fan of gdb, coredump, vi and edlin ;-)
We are not in 1970 anymore IMHO ...
Rgs,
TM
I would still use an IDE when given the chances (if it's easy enough to set up), even if a simple one. I use Code::Blocks for C programs for editing, the projects (it keeps tracks of source files and build options) and for the build button (so, text editor and make all-in-one). Granted, I don't use many of the features, such as autocompletion (which always gets in the way) or smart tabs (sometimes gets in the way, I'm happy enough with just copying the indentation of the previous line).
only an IDE could love AbstractSingletonProxyFactoryBean.
Uh huh? Naturally, class names such as ASPFB and GDMF and RSAP are evidently more lovable. So much simpler to write...
If you have ever written code in Python, you realise how much trivial stuff you have to do in Java which is hell without an IDE. I'm not saying IDEs are useless, they are great and can do awesome stuff for a developer, but Java has a serious problem where it's practically unusable without a massive IDE.
-- Lattyware (www.lattyware.co.uk)
... and Visual Studio 2010 with ReSharper, and it's the most amazing thing ever... at least until the company decides to upgrade to 2012, which is ugly but it has a lot of new and really useful features.
I'm not going to rant since I know a lot of you would rather forget proprietary software exists, but the rest of the IDEs I have tried to use can't compare, and sometimes even get in your way.
Syntax highlighting and parens matching doesn't really help the beginners. Instant feedback for programming errors is great, you immediately learn about the syntax on the go. Then the debugger is also a great tool (even though I think you should first think, then code, then think again and only as a last resort start the debugger).
These are not Eclipse-unique features, you can get such features with many setups but an easy to install IDE that satisfies your needs and is easily extendable with plugins that integrate seamlessly with your IDE (for example Findbugs).
It's almost like Emacs done right for Java. Well, as right as an IDE can be done.
I don't buy the argument that 1 class means 1 file is a problem (btw, this only applies to public classes anyway). If your project is large enough, you still get navigational problems even if you'd crammed 10000 lines into files (please, don't do this).
UnNetHack: NetHack Improved!
I would argue needing a debugger is also a sign of language flaws. Debuggers help you find issues with your code while it runs. I've found that so much of the time those kind of issues are from stuff like Null objects - where you get an exception from a null object and then have to crawl up your code finding out where it came from. If the language was sane and threw exceptions on problems rather than returning null, there would be far less issues.
Not saying that debuggers are useless or that every problem a debugger is useful for could be solved, just that if you find yourself needing it often, maybe it's a sign something is going wrong with the language.
-- Lattyware (www.lattyware.co.uk)
I would argue needing a debugger is also a sign of language flaws.
You would lose that argument.
Pros:
* Syntax highlighting
* Brace matching
* Symbol autocomplete
* Error highlighting (XCode FTW)
* Go to Definition/Declaration
* Debug with all the above features in place
Cons:
* Some guy says they have a smell, but actually he doesn't like Java (so don't use Java)
I could write code without an IDE, but I wouldn't want to maintain someone else's code without one, and I regularly port (alone) MLOC codebases.
And that's why these days we use Vim... not vi... Oh yeah, and we get shit done. Fast.
amiright?
What we have here is another attention seeker trying to appear enlightened by saying something "counter-intuitive" or "against the grain". It's a bit like those people that go out of their way to let you know that they don't think Dark Side of the Moon was the best Pink Floyd album, because their opinions are so diverse and more informed than all the "sheeple".
IDEs are a smell? What? No mate, you smell. IDEs drastically improve productivity. Yes, part of that is code navigation - mature libraries and frameworks such as the STL, Java, and .NET are HUGE - not because they are poorly designed (though that may also be true; correlation != causation), but because the sheer number of features makes library and framework searching essential. No human could possibly use these libraries as efficiently without code completion or prompting, except for the parts they use most frequently. IDEs make the libraries and frameworks discoverable.
That's not even to mention all the OTHER benefits IDEs bring - integrated debugging, refactoring, static analysis, test coverage analysis, code style management, build chain management, source control integration....
Yeah, yeah, I bet this guy is 1337, uses ONLY notepad / ed, hand writes his make files, and is the most badass coder on the entire planet. The problem is - nobody cares. Everyone else is more concerned with getting the job done efficiently. IDEs are simply essential in the large code bases I work with every day, and that would be true whether I were dealing with a million lines of Java or a million lines of Haskell / Python / Whatever this guy thinks a "good language" is.
That's it, cherry pick a comment without reading the rest of my post, and don't bother to respond to any actual argument in it.
-- Lattyware (www.lattyware.co.uk)
I call bullshit on this. One of the major reasons to use a modern IDE is the support for refactorings. Renaming variables, fields, and functions/methods is a major pain in the butt in any language if you have to do it manually. Having tools to do this instantly is a major reason for using IDEs and the like.
Also, whether classes are located in a single file or across multiple files is completely irrelevant. Having a tool that allows you to navigate efficiently in the code improves performance of the programmer in any case.
The reason that people aren't using IDEs for niche is probably that the tool support is nowhere near what it is for Java.
The problem is that Eclipse is one of the worst IDEs ever, and Java, as a whole has crappy IDEs. IntelliJ is by far the best, in my opinion, since it is less buggy, crash prone, and confusing than Eclipse, which is more a collection of components than it is an IDE - but even IntelliJ is still subject to Java GC pauses. Really, you can't write a good IDE in Java, and therefor Java developers have bad IDEs. Visual Studio isn't a really great IDE, but at least it doesn't pause while you are typing, and it has a unified sense to it that you don't get with Eclipse. MonoDevelop is pretty good too, or FlashDevelop, or really any IDE where at least the UI thread isn't subject to GC.
Well that's bullshit. The biggest problem with development these days is not the language itself, but the 100s of 3rd party mostly-open-source libraries that you have to use. Or else go reinventing the wheel which is worse.
And IDE helps you see the reference for these libraries much easier, using autocomplete and automated documentation lookup. On top of that, navigating your own code is much much easier. Add debuggers and profilers, granted, somewhat less useful in server-side environment but still useful. Semi-automated refactoring though is great, and eclipse does that quite well.
I've done my share of development using nothing more than a text editor. But I prefer to use IDE when I can- they make me much more productive. Of course I still make sure code can be built & deployed using plain command line tools- for Java Maven is great.
--Coder
Eclipse starts to get annoying type lag around 30k lines of code in a single file, as you get bigger and bigger upwards to 100k or more, it can take several seconds between characters you type. Now some people say you shouldn't have a single file with over 100k lines of code, but some of us like using old school procedural with just a sprinkling of OO.
God spoke to me
It's just as good as the artisan who uses it. You can use a hammer to drive in a nail . . . or to smash a vase. It depends on how you use it.
An IDE won't make a good programmer write bad code. And it won't make a bad programmer write good code. Unfortunately, a lot of manager types assume that if they buy some expensive tools, their programmers will automatically program gold from straw.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
Most bizarre conclusion I have ever seen. Of course you can have highlighting and other editing tricks (autocomplete, etc.) in a text editor. But once you add things like unit test integration, deployment, and most importantly an interactive debugger where you can step through your code, you have a proper development environment. Running tests can be done at a shell prompt, but debugging not so much. And if your text editor ticks all these boxes, including interactive debugging (I'm sure emacs can for example), then your text editor IS A FREAKING IDE ALREADY. I'd like to make the inverse conclusion of TFA: since we have proper IDE:s we can now allow the code in modern languages to be structured an way we want. A good IDE should never have you worrying about files, just code.
I'll take a shot then.
A debugger can give you lots of of information when the exception occurs. You can visually watch the flow of program execution, inspect the values of all variables in scope, modify them on the fly, or even execute arbitrary code statements while you are in the middle of debugging the issue, say at a breakpoint just above where the error occurs.
A thrown exception doesn't give you any of these things. It provides better logs, maybe, but a debugger gives you so much more. An exception gives you a stack trace; a debugger opens up the guts and lets you poke around as much as you want.
Your assertion that needing a debugger is a sign of language flaws is absurd. Period.
I would argue the opposite. If you execute code it will invariably do things you didn't expect, regardless of language. You either debug or guess. I saw no argument as to why guessing is preferable to interactive debugging? I agree that "null" is a language smell, but there are concepts like code contracts that lets you have non-null enforced etc. There are a million other things you can debug regardless of language.
Sounds like somebody is a shoe-in for a Light Table licence.
So why do Java coders turn to Eclipse?
I don't know. I just don't know.
Exceptions are intended to be used when a program hits unexpected or fatal issues which cannot be handled locally, and often the low-level library code isn't in a position to be able to judge whether something qualifies as worthy of an exception or whether it's an expected part of the processing cycle and can be safely be ignored.
Take for example asking to open a file for reading and the file not being available for some reason. If I'm just copying a large directory structure then I can reasonably expect to not be able to open a few files due to permissions and, while I'll likely want to log these and display them, treating it as an exception wouldn't be suitable. If my code is part of an online application and it was failing to open a configuration file which it needed to connect to the database then the error would be worthy of promoting to an exception if it could not rectified in the code which detected it. Ultimately though for this type of 'It could be serious, it could be nothing' then the decision should be left to the client code rather than the library.
In my mind a better approach to fixing these type of errors is better support of types which cannot be set to null. For example if I have a FileHandle variable which cannot be set to null and the File.Open() method returns a nullable type then there's going to be a compile-time error, which is the best type of error. This will point out where I'm 'assuming' that the value is not null and as I'm fixing the compile error I'll naturally add the correct checks as the 'This could be null..' issue has been highlighted for me.
404 Not Found: No such file or resource as '.sig'
While I agree with the author about Java, there are other things why I prefer to use Eclipse (over other editors/IDEs)
* The compare editor. Especially in conjunction with the SVN plugin. Very very useful.
* I can have more than one project open, and edit and compare files in both. I may seem like something trivial, but too many other IDEs are deficient in this regard.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
In most languages you don't need a debugger for stuff like null pointers; perfectly fine exceptions are thrown and reported telling you exactly what you did wrong. When is the last time you ever used a debugger to track down such a bug? You use debuggers to analyse why some algorithm isn't worked as it's supposed to; for finding flaws in human thinking.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
TL;DR - Let's all ditch IDEs and go back to Notepad/vi/emacs/edlin.
Code generation in Eclipse is a breeze, it easily creates framework classes where you can plug in your code. Directly jump to classes, view javadoc when you mouseover any element, jump between occurrences of text within a file, seamlessly integrate with the version control system of your choice - it has everything to properly work with a modern software project that can have hundreds or thousands of classes and files.
And the same goes for Netbeans or Visual Studio or any other IDE of choice.
Finally, tell me how many real world projects use Haskell, Clojure or Scala as compared to ones using Java/C/C++/Python/Ruby/PHP/Perl. I don't exactly see dozens of job openings for the former on various job boards. You work with what you've got, unless you're an ivory tower academic who's only concerned with the design of a language as opposed to its real world usage.
"..One hosts to look them up, one DNS to find them, and in the darkness BIND them."
"Renaming variables, fields, and functions/methods is a major pain in the butt in any language if you have to do it manually. Having tools to do this instantly is a major reason for using IDEs and the like."
You mean like "%s/old name/new name/g" that the vi editor has had since the 80s? Perhaps you should try using a programmers editor. You might be surprised at just how little extra an IDE gives you.
"Having a tool that allows you to navigate efficiently in the code improves performance of the programmer in any case."
2 or more xterms and "grep". I find that combination far more efficient than some bloatware IDE. Admittedly I'm a C++ coder, not java, but I've used some IDEs and found them wanting. They want to be an entire coding "enviroment". Thanks , but I already have one - its called the operating system. However YMMV.
TypeMismatchException: expected integer, found float at or near line 237. Bailing...
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I have done projects in both jEdit and Eclipse. I have also done C++ projects, a language that allows you to stuff the interfaces in a few or even a single file. I have also dabbled in multiple other languages.
Basically, regardless of language, if you want to be productive, you want auto-completion. Yes, you can do without. Yes, having APIs in a few files makes it a bit more convenient to look them up. However, looking them up alone is too slow, especially if you are working on a bigger project with multiple people. Even if the interfaces are ALL in a single file (bad idea, generally), you still have to spend time to sift through it and you'll need to sacrifice precious screen real estate to display it. However, it's simply to slow to look up every time whether your coworker has called a function wiggle-the-frob or jiggle-the-frob every time (and yes, you keep forgetting it if the project is large enough).
And no, "you should be thinking a lot about each line of code" generally does not apply in real projects: The really smart parts of the code can take 0.5-2 days to deep thinking to write them, but then you spend the next 2 weeks on code that just churns and moves data around which is mind-numbingly dumb but necessary work. In the latter part of the coding, which takes up a lot more time, you already have the code roughly mapped out in your head before you even start writing it and you just want to write it down as fast as possible to get back to the interesting parts.
Also, refactoring: Regardless of language, if you want to rename a method, function, whatever, you want something that does it for you and understands the language. No, sed is not good enough, you don't want to fire some sed command, which has no awareness of the code semantics at 500+k lines of code and hope it does the right thing.
As far as the "thousands of small files, each class has its own file" thing goes: It has advantages and disadvantages, the plus side being that classes are self-contained. You can easily take them out, move them around, put them somewhere else without having to shred apart some big interface file and hope that you caught all the method declarations. Also, when you organize interfaces in larger units like namespaces etc., you do have to think about how to organize those. Yes, it may be worth it, or it may not be, but it's an overhead if you decide to do it and you'll have to stick with it, too.
As far as the "Java is so verbose" meme: Sometimes it is the language, sometimes it is the people. People in large Java projects tend to over-engineer things (I'm not entirely sure why people do this, maybe abstraction is over-emphasized) with abstractions layered upon abstractions and then you end up with something like the "AbstractSingletonProxyFactoryBean", but you don't have to do that, if you put some effort into, you can keep it simple.
There are some parts that I really find needlessly verbose in Java like catching "checked" exceptions: Even when you provide PROOF that the exception CANNOT occur, you have to add 6 lines (in Allman style, it's a bit less in canonical Java/K&R style) of completely useless code. And yes, functional languages are very nice and elegant and I love them to death, but if one is honest, they haven't caught on, maybe that's a smell on its own.
I clarified later that I was talking about needing a debugger often, not at all. Clearly a debugger is a very useful tool, for all the reasons you stated, but in Java you often have to use a debugger to find trivial bugs because of flaws in the way the standard library operates - that is where I was saying there is an issue.
-- Lattyware (www.lattyware.co.uk)
Then why can you catch an exception? Exceptions are the perfect tool for this kind of job - you might not be able to open that file, what will you do if you can't? Catch that exception and deal with it. It means you get the feedback at the right point.
-- Lattyware (www.lattyware.co.uk)
I would argue needing a debugger is also a sign of language flaws. Debuggers help you find issues with your code while it runs.
The biggest code smell is the lack of an ability to attach a REPL to a running program so you can poke around in it, define new things at runtime and experiment with them until they work, and then translate that back into "fixed" code in a source file. But that's not really the way you do things in Java (and a few other languages as well).
"Little does he know, but there is no 'I' in 'Idiot'!"
The problem with the null pointer exception is that you get told about the effect of what happened, not what caused it. Say I try and do x, which fails, and then gives me null - when I try and use that x later on, I get the exception, and have to trace back up my code to find the issue. If x threw the exception when the problem happened, I would know why that object isn't there, which is far, far more valuable and easy to work with.
-- Lattyware (www.lattyware.co.uk)
In general, if you need a debugger while developing your code then you may not know what you are doing. Maybe you are developing very special stuff, otherwise the intensive use of a debugger means either lack of experience and/or skill..
I'd argue against it.
More importantly, they allow you to examine the state of your program when an issue arises. In other words, you can test, quite on the spot, any assumptions you have about the state of the program, and thus can more easily determine what went wrong.
Yes, about everything you could do with a debugger you could do with well-placed print statements, and lots of recompiling and rerunning. But why waste your time with that if you can just look up the value in the debugger without changing the code?
Not too long ago. And it is WAY easier to debug it than in Python. I wish I had your exceptions that get thrown and tell you exactly what you did wrong, and not just tell you that the pointer you just access was NULL.
the absolute refusal of C-typists to learn to program properly. And the blind refusal of good programmers to understand the difference between typing lots of code and actual software engineering. In my 22 years in industry, the number of actual software engineers I've encountered can be counted on one hand (literally). There were a fair number of good programmers. But for the most part, it is pretty dire.
And don't get me started on software architects.....
No amount of IDE religious belief will make you a good typist/programmer/engineer.
> but in Java you often have to use a debugger to find trivial bugs because of flaws in the way the standard library operates
Could you mention one or two examples? In my experience the standard library is pretty good.
I'm not an ubergeek, so maybe my view isn't as good as the guy who wrote this article, but aren't all large projects, regardless of language, harder to manage?
I've worked maintenance on projects done in an old procedural style. I can't believe anyone in 2012 would think that OO is not an improvement and actually makes managing a project harder.
Do you have an example of this? I rarely need to use the debugger in Java. I can usually spot the bug in a few minutes looking at the code. But I use IntelliJ not Eclipse.
log.error(e.getMessage(), e) will give you the stack trace.
I would argue needing a debugger is also a sign of language flaws. Debuggers help you find issues with your code while it runs. I've found that so much of the time those kind of issues are from stuff like Null objects - where you get an exception from a null object and then have to crawl up your code finding out where it came from. If the language was sane and threw exceptions on problems rather than returning null, there would be far less issues.
Not saying that debuggers are useless or that every problem a debugger is useful for could be solved, just that if you find yourself needing it often, maybe it's a sign something is going wrong with the language.
Did you even bother to try to understand what he said before you replied with your nonsense?
Here, let me help you: he uses the debugger and dynamic class loading as a REPL.
Nulls do not necessarily indicate failure. It's only an exception because an operation using it as a base was specified.
Then you can swap out 'using a debugger' for 'spending time looking at the code' - neither should be necessary if you get an exception when something fails rather than returning null.
-- Lattyware (www.lattyware.co.uk)
Ugh, as always happens I poorly phrase the first sentence of my post and everyone jumps on it. I wasn't saying debuggers are bad, or at least wasn't trying to - just that in Java, the standard library has a tendency to return null when something goes wrong rather than throw an exception, which means you don't get told about the cause of the issue, just when it shows up later as a null pointer exception. This can lead to using the debugger a lot or looking through the code to track it down. I hope that clarifies my point.
-- Lattyware (www.lattyware.co.uk)
That's my point, that in Java, nulls do get used to indicate failure, that's when they are a problem.
-- Lattyware (www.lattyware.co.uk)
I (professional Java coder since 1998) absolutely agree. Java is hardly human-writable, even if it were only for the import statements. Without the existence of some very good IDEs Java might very well not have been as popular as it is today. But it is.
Is this a problem? Apparently not in practice. Would I rather have a more dense, less IDE-dependent language? Yes. Are such alternatives available and do they come with an enormous ecosystem of supporting libraries? Nope...
0x or or snor perron?!
Ugh, as always happens I poorly phrase the first sentence of my post and everyone jumps on it. I wasn't saying debuggers are bad, or at least wasn't trying to - just that in Java, the standard library has a tendency to return null when something goes wrong rather than throw an exception, which means you don't get told about the cause of the issue, just when it shows up later as a null pointer exception. This can lead to using the debugger a lot or looking through the code to track it down. I hope that clarifies my point.
I agree that APIs should avoid returning null wherever it is reasonable to do so, and that the standard Java library is not perfect. However, I am darn glad the standard Java library is as comprehensive as it is. It saves me a lot of time having to hunt down third party libraries that may or may not be affordable, or may or may not have licensing terms that I can accept.
I think Python is much worse in its "anything can throw an exception at any time" design, and I am glad I don't have to use it very much anymore.
While I am not fond of Java's inability to define functions with a proper syntax, it's not as if the alternatives are noticeably better as far as not needing navigation. In the end, it all comes down to program complexity. A developer still has to know the code he needs to use, and for any program of reasonable complexity, you need to either remember it or use an IDE to easily access it. And given the ungodly number of libraries we use today, this happens even when you are coding in Javascript.
If anything, the fact that Java is statically typed makes it easier on IDEs to tell you all the details of available classes. IDE support for Scala will still have you remembering signatures that Java wouldn't have to. And we all know the fun of Javascript, where most IDEs will not be able to guess what properties a object has, because the only way to know is to run the app.
Don't get me wrong, I sure wish for at least Groovy-like function support, unlike, say, the horrible things people do to try to write functionally in Java (welcome Guava abuse!), but the only way some of those languages make you not 'need' and IDE is because IDEs can barely understand the languages. I'd not call that a good thing.
Yeah returning null is usually an error. Devs should read Effective Java more often. ;) However you'd still get a stack trace with a "caused by".
I would argue the opposite. If you execute code it will invariably do things you didn't expect, regardless of language.
Isn't that a clear indication that you were unable to express what you wanted the program to do in a clear way?
I'm not saying that a perfect language exists and I have certainly encoutered code that were hard to write in a way that made it obvious what the code did in the languages I knew.
I still wouldn't rule out that this is a flaw of the languages.
The standard library is (mostly) great, I agree on that point, I'm just saying this is a problem I have with it. As to Python throwing too many exceptions, completely disagree, it makes it so much easier to work with - if something doesn't work the way you expect it to, it's going to throw an exception. Knowing that is so much nicer.
-- Lattyware (www.lattyware.co.uk)
When was the last time someone wrote a 3D game engine in Notepad ?
I think the eureka moment should be when you realize that any language can fall into the trap that you describe. There's reasons for the complexity. Whether they are for compilation/parsing performance, or for some type of design pattern to elegantly solve a problem.
I've got a buddy down the hall who grew up ASP and VB. He uses notepad for development, and complains about not having pointers in Java. Syntax highlighting/completion aside, it takes him forever to write even some of the most basic classes. It's a constant game of finding something to copy and paste. What clicks off in my head is that when you're copying and pasting so much, someone probably already wrote a library for what you were trying to do. Hence additional files, includes, whatever it is... it's more of that whole lots and lots of small files that are mentioned as a downer in the op.
If you're complaining about OO patterns, that's not language specific. Heck, even SAP has an OO equivalent.OO is a byproduct of merging human conceptualization and computer language. It becomes more "natural", arguably, for a developer to understand. Is that a problem of the language? No. I can write just as much spaghetti code as OO in Java, well, pretty much any language for that matter.
Now for your humorous AbstractSingletonProxyFactoryBean. If you're writing a webpage with some fancy graphics on the front and not much user interaction, then you'll probably come across this class and think wtf would anyone ever use it?
If you come from the data processing world with many systems working on the same data, you pretty much don't live without it.
This is equivalent to growing up in Mexico, never even hearing of the word snow, and then see someone walk by with a pair of snowshoes in hand. Do you point and laugh first, or do you try to understand why they have snowshoes?
Snowshoes are obviously everything that is wrong with footwear.
So basically the author claims that, if the language is "good enough", there's no need for an IDE, as for "sane languages" like Haskell,.
.EclipseFP (http://eclipsefp.github.com/)
But Haskell itself has IDEs in development that do way more than "syntax highlighting" and "parent matching". Examples:
- Leksah (http://leksah.org/)
-
There was also talk about a "Visual Haskell " based on MS Visual Studio...I have no beef with Haskell, on the contrary, from what I heard, it seems like an elegant and powerful language. But is Haskell becoming an "insane" language like Java because "IDEs are a language smell"?
Isn't that a clear indication that you were unable to express what you wanted the program to do in a clear way?
Not necessarily unable, just didn't. Could be for other reasons (e.g. a simple mistake).
Android got it right when it allowed developers to choose their own tools. If someone wants to use Eclipse, they can. If I don't, I don't have to. I know that a fail is going to happen when a platform absolutely forces me to use certain tools. Blackberry not only forced you to use Eclipse, but forced you to use Windows. And they failed. Even Microsoft's monoculture allows you to use your own tools. The only example to the contrary is Apple's closed ecosystem which forces you for all practical purposes to use Xcode.
To succeed, release a SDK for your platform and let developers choose their own tools. Simple as that!
The problem is "I would argue needing a debugger is also a sign of language flaws." is your summary sentence. If I was to only read one thing about your entire statement, that should summarize everything, which it doesn't.
You just don't proof read well at 4:34am(my time, but that's the joke).
You are entirely correct, I started with a terribly misleading sentence, I accept that error.
-- Lattyware (www.lattyware.co.uk)
Many times a stack trace isn't useful in itself without the state at the time. It does give you a great starting point, but it doesn't always have everything you need.
The place where something finally called a method on a null is not necessary place where the bug is. The question is why that variable has a null value at that moment. You will not find it in the stack trace.
So why do Java coders turn to Eclipse? 'Because [of] a combination of shortcomings in the Java compiler and Java's OO nature,' explains Faler, 'we end up with lots and lots of small files for every interface and class in our system. On any less than trivial Java system, development quickly turns into a game of code- and file-system navigation rather than programming and code editing. This nature of Java development requires IDEs to become navigation tools above all.'
So in other words, we blew it by giving up COBOL, where everything is easy to find because it's all one big source file.
Amusing observation: I once worked in a shop where the main COBOL program in the system was so big, it blew out the COBOL compiler. More that 64,000 distinct paragraphs in the PROCEDURE DIVISION.
An IDE is an intelligent development environment. I've progressed over the years from punched cards to line-mode editors to full-screen editors to simple edit-and-debug frameworks to Emacs and ultimately to Eclipse and its relatives. I can fall back, and occasionally do, but the reason I prefer IDEs is because navigation is only a small part of it. Auto-suggestion means I don't have to remember details of each and every method I use. Dynamic JavaDoc display means I can RTFM without leaving what I'm doing. An integrated debugger means I don't have to litter my code with diagnostic print statements. The database plugin allows me to view and tweak the databases. Mylyn makes it easier to switch contexts when I have to drop everything and make emergency fixes or alternate between tasks. The refactoring plugins allow me to keep my codebase cleaner without a lot of manual effort. And so forth, and so on...
IDEs also have their darker side. Pound-foolish managers expect that they can employ cheap monkey-coders and let the IDE do the advanced thinking and that can result in some real horrors. Too much reliance on an IDE can result in projects that can't be easily maintained or can't be handed off from one person to another (since too much of the build process in in IDE customizations).
Still, an IDE that's properly employed in the hands of a skilled developer can be worth its figurative weight in gold. It's far more than just a navigational tool.
WTF is Clojure & Haskell, says the man who writes large scale java apps?
IMHO, you really wanted to plug Clojure and Haskell and diss Java and the IDE angle is just you trying to make it into Slashdot story. But there are a million and one new FAD of the day and they don't last long .
Also names like AbstractSingletonProxyFactoryBean, well I don't know what it is, but it's Abstract (i.e. a base interface rather than a specific implementation), Singleton (one instance does it all) , Proxy (substitutes for something else), Factory (Creates something, so most likely he means ProxyFactor meaning it creates theses proxies), Bean (either Rowen Atkinson comedy alterego and related to Java Beans).
It's like German compound words, they are long, but they just contractions of word fragments. Nothing wrong with them, other than they make comedy harder, since the first fragment is usually the spoiler for the whole word.
Clojell and Haskure can probably just be made to disappear simply by mispronouncing them often enough that they are forgotten ;)
It's not all that hard to write fairly clean and simple code in Java. But the "OO experts" would sneer at you if you don't use interfaces, annotations, factories, endless config files written in xml, etc., etc. Java gurus insist on heaping more and more required baggage on top of the heaps they started out with.
Have you tried reading perl code? Or mediocre to bad C/C++? It's impossible to decypher most of the time.
I consider Java to be the easiest language to READ code in and to understand it. Most of the time it's possible to quickly decypher even crap code written by newbies. I'll live with having to write slightly more verbose code or slightly more boilerplate code just for this reason. Or with having to use an IDE to do that for me.
--Coder
The IDE shields you from the system, which you really need to know backward and forward when you're programming it. You need to understand how libraries work on your system, you need to understand the compile and link cycle, you need to understand dependencies and the IDE hides all that from you. If you haven't spent time writing your own makefiles you won't understand not only how easy it is, but how universally it works on every systems (including Windows ones.) By the time you're to the point where you understand that stuff and could move to an IDE if you wanted to, you probably will hate having those details of the system hidden from you. I've never seen a project so big it couldn't be managed with a good text editor and make! I've been known to hand-author ant and maven buildfiles, too, and it really highlights Java's nasty requirement to crap directories everywhere.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
You'd have to be a masochist to choose a basic syntax hilighting editor over an IDE without an extremely good reason. I realise there are a lot of good reasons but a language so perfect that an IDE is unnecessary is not one of them.
The place where something finally called a method on a null is not necessary place where the bug is. The question is why that variable has a null value at that moment. You will not find it in the stack trace.
If your logic is so complicated that you can't tell where a variable should have been assigned, your code is already an unmanageable mess. Add preconditions on the arguments to your methods and enforce them by throwing an informative exception if they are not satisfied; that helps hugely. If it doesn't, it's time to also do postconditions and invariants. If you don't understand what those preconditions and postconditions should be, that's a much more important problem than where your code is throwing a NullPointerException...
"Little does he know, but there is no 'I' in 'Idiot'!"
I use vim with ctags for file navigation, and there is an add in that does decent intellisense but I don't use it. Just run ctags in all the libraries you are using and your own project (yes its manual) and add references to those tag files in your .vimrc. Then ctl+] and ctl+t will navigate to and back from keywords, its not great about using c++ context to know which instance of that keyword it should jump to. If you try to go the definition of the variable "counter" and people have been naming lots of private variables that, then you'll have a long list to pick from regardless of namespace or class, but its good enough usually.
I haven't found a decent gdb add on for vim yet though, I heard there was a decent one for emacs. But debugging with gdb is painful. It is powerful, but just plain hard to use, it feels like looking at my code through a drinking straw.
When I'm working on windows I do appreciate the intellisense, and I don't think its giving me bad habits. The debugging is much much nicer as well. Xcode is somewhere between the two.
refactor the law, its bloated, confusing and unmaintainable.
The reason why you break a large "complex" system into small interface files is exactly for EASE of continued development.
This guy wants to write one large file that contains all of his classes and interface (or lack there-of) and therefore only needs a text editor. This guy is not worth his salt as a developer.
You can't build large systems this way. Monolithic FILES (opposed to an IDE) are full of old, unusable code and prone to significant defects when worked on by a team of people.
Also I tire of the idea that I am not a real programmer because I use an IDE which auto-completes and has syntax highlighting. I build apps, I don't spend hours making one line of code execute as efficiently as possible. There is a point of diminished returns where the amount of time you toil over every line of code does not translate into faster more efficient code, so I work at the high level building large complex systems with relative ease, efficiency, and with adequate performance that is acceptable to the clients I work for. Also I finish a project on time rather the going 6 months over.
I am sure this guy is just lamenting the fact that Eclipse isn't the greatest IDE out there, but the idea that you don't need an IDE for the reason that it creates lots of small files that this guy considered "complex" proves he is a moron and should be ignored.
BTW a good IDE allows you to quickly and easily navigate lots of those pesky SOLID code files. If you don't know SOLID, look it up.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Editors that automatically hide your garbage are a smell. But then, so is the code that needs it.
Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
I would argue needing a debugger is also a sign of language flaws.
I agree, but for a different reason. A good language is one in which debugging means finding logical flaws in the design of a program; no language can truly achieve this ideal, but some languages come closer than others. I do not think we will ever get rid of debuggers; I think debugging will change, though, when languages like C and C++ go the way of the dodo.
Here, for example, is a tool that helps with debugging high level logic:
http://alloy.mit.edu/alloy/
Give it a try some time; you'd be surprised by how effectively it can find bugs in designs, and by how effectively it can convey what those bugs are. This is the sort of debugging we will need going forward -- not debugging mechanics, but debugging high level logic. Knight Capital didn't go bankrupt because of a null pointer.
Palm trees and 8
Exceptions are expensive and should be reserved for when things go massively wrong. Returning null is generally the way things should work if you want an error to be recoverable at all. Exceptions are way way way overused.
Example- Android will throw an exception if you try to hide a dialog window that was already hidden. Why? The end result is what you wanted- it just means every dialog hide has to be exception wrapped (especially since there are timing issues you can't avoid that will cause this).
Another example- file IO. Trying to open a file that doesn't exist is a common case and should return an error, not throw an exception.
Basically if you think its likely someone will ever want to catch the error rather than see a stack trace in a log there, it probably shouldn't be an exception.
I still have more fans than freaks. WTF is wrong with you people?
Petzold is the old school C programmer and writer who authored many editions of the classic MS Press "Programming Windows" guide to writing GUI apps in C and (later) C#. He's never been a big fan of IDEs, but uses them anyway.
The premise of the article is that Java is broken so it needs an IDE.
I wonder how dependent Javascript programmers are on a good IDE.
There's your problem right there. You don't have proper dependency management and separation of concerns if you need thousands of files in a single project.
Exceptions are intended to be used when a program hits unexpected or fatal issues which cannot be handled locally
According to whom? I see exceptions being used for correctable errors all the time; here, for example, is an exception that is thrown for a correctable error, in Java:
http://docs.oracle.com/javase/7/docs/api/java/io/SyncFailedException.html
Yes, this is a correctable error: if you can ask the user to fix this problem, you can continue from some point defined by the thrower of the exception (perhaps retrying the sync operation). Of course, Java does not support such a thing; however, this is a thread about language deficiencies!
If I'm just copying a large directory structure then I can reasonably expect to not be able to open a few files due to permissions and, while I'll likely want to log these and display them, treating it as an exception wouldn't be suitable
Why is that not suitable? I'll have my exception handler log the exception, then I will try to open the next file in the list. You do not even require restarts here; in Java, this amounts to placing a try...catch in the body of a loop.
Ultimately though for this type of 'It could be serious, it could be nothing' then the decision should be left to the client code rather than the library.
You forgot, "This is serious, but it can be corrected." Running out of space on a hard drive, a thumb drive being removed while it is being read, etc. Without a good exception/restart system (or continuations if you want to be more functional), your client code winds up being far more complex (think about how you would deal with a thumb drive being removed while some records are being written if you do not have a restart mechanism -- now imagine if your catch block could say, "Retry the operation" and if the exception is not thrown again, your code continues as if no exception was ever thrown).
The problem with exceptions in most of today's popular languages is that they do not merely signal an error; they also destroy the entire call stack from where the exception was thrown to where it is caught. A better approach, at least in my opinion, is for the exception propagation to leave the stack intact until the end of the exception handler. This would allow the exception handler to invoke a restart, which can be viewed as a "dual" of an exception: a restart would cause control flow to switch to some point defined by the thrower, and would invalidate the stack of the exception handler (and the program can then continue as if there had never been an exception, except for whatever side effects the exception handler has).
Palm trees and 8
The issue here is the weird for() construct which is halfway between a range loop(*) -- which shouldn't reevaluate its upper bound expression -- and a while loop -- which should.
(*) Which, btw, is almost always what you want when you use a for loop.
Does that make me a more flawed programmer than most, because I rely on a computer to do what I could otherwise do by hand, but do not do the latter simply because it would take so much longer?
File under 'M' for 'Manic ranting'
Or a necessity. Would you rather have a million line file or 1,000 1,000 line files (categorised and organized).
Troll is not a replacement for I disagree.
Not at all, my point was that when a standard library function returns null on an error, that error then shows up as a null pointer exception later in the code, which means either debugging or searching through code to find the cause, rather than just reading the exception. By changing this behavior, we could reduce the need to debug.
-- Lattyware (www.lattyware.co.uk)
The idea that Eclipse is needed for Java development is ridiculous. I have been using Java for 15 years on projects big and small... vim and tmux are all I need.
I can't imagine living without an IDE. Having the ability to actually debug my code in-place from the same place I'm editing it, increases coding productivity like crazy, and I can't even imagine anyone seriously trying to argue otherwise. I do agree that it's commonly thought that you should put each class in its own file, and that that's just silly, that it's a lot more readable when multiple classes that are tightly related are put in the same file so you can see them all at once and see the tightly-relatedness. I'm not sure that really has anything to do with having an IDE or not, though.
On the other hand, Eclipse certainly does have a massive smell of its own. He says "if you suffer from tool frustration, it's not necessary your tools that are poor, it may be that your language sucks, or you're not using it correctly", but no, if you're talking about Java, where the only real IDE is Eclipse... it's because your tool sucks.
Modern IDEs can be great, but using them does come at a cost, so I think people end up using them in situations where there is a net benefit (and the opposite is true - people don't use them where there is a net cost to using an IDE). Personally, using a full-fledge IDE often leaves me with a feeling of it getting in the way, but I tolerate it because with some languages or platforms the IDE is still a net win.
This is nothing but an anecdote, but we have several non-trivial projects (100kLOC+ each) in C/C++, C#, ObjC, Java, and Python worked on by about 10 people (so not huge by any means, but not so trivial as to be meaningless) and:
* Everybody uses an IDE for the ObjC, C#, and Java projects
* About half use an IDE for the C/C++ projects (rest use vim)
* Nobody uses an IDE for the Python projects (most use vim)
What's interesting to me is that as far as I know everyone has /tried/ not using an IDE for Java/ObjC/C#, and everyone has tried using an IDE for Python, and there has never been any sort of mandate to go one way or another, and so the present situation is the result of everyone sort of landing where it feels most natural and where they are the most productive, and that we have the same results regardless of proficiency in a particular language (i.e. the C# experts and C# noobs end up with the same development environment, as do the Python experts and the Python noobs). The same also appears to be true regardless of language affinity - lovers and haters of Java use the same environment, lovers and haters of Python do as well, etc.
I do wonder if there is some sort of correlation between environment and the language. I know this is pretty subjective, but for me languages like Python feel like they rarely get in your way, and so it's interesting that when people in our company use Python, they gravitate towards development environments that are similarly lightweight. And conversely, for me a language like Java tends to feel like it gets in the way a lot (as in, you have to do lots of things that are satisfying the demands of the language that aren't directly tied to the problem you're trying to solve), and an IDE is indispensable because the IDE helps shoulder some of that burden.
for (int j = 0; j < getCount(); j++) {
And what if in the loop something had been altered to extend the results of getCount()? Bad coding I would say, but you are discounting that possibility with your fix...
In reality though, a good compiler will optimize that away if it's really just generated an accessor method for that call. In reality there is no problem with coding against accessors for modern languages because the compiler will fix performance problems like that.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It should say "IS the IDE a bad programming enabler?" so that we could give the standard answer of "No" and move on.
Fully agree. The unhandled NullPointerException is nothing more than bad programming
That stern looking old fart is John McCarthy. He probably did more for computing that all of us put together.
I do that all the time in Java using Eclipse. If I have a problem in a function, I have a breakpoint there. When it gets there, I can see what all the variables are set to, and what the code has done. I can change the code, save, and it restarts at the beginning of the function.
The more people I meet, the better I like my dog.
In languages with side-effects exceptions force the caller to handle the error if they want to continue operation, instead of silently assuming that everything went right and inadvertently propagating a potential problem all the way up to the first place where the error condition actually matters. So in my opinion it's actually the exact opposite of what you state: if you would like someone to catch and recover the error rather than just bombing out late and at odd times due to bad programming, throw an exception. It'll bomb out early, and give the offending programmer a good kick in the shins about not checking for errors. ;-).
That doesn't mean I think both of your examples are fine: the first case is just stupid - there IS no error if you're hiding a dialog that's already hidden. The second case should be local: you're opening a file, and if you then don't have a file descriptor you're going to have a more serious error REALLY quickly afterwards (unless you have terrible programming, but then you have terrible programming, and no amount of exceptions will help there!). In the file case it's actually even more different: there's usually no error code, you just have a valid file descriptor or you don't, and people learn quickly, so exceptions are not necessary.
When it comes to error/success return codes.... I've seen a lot of code containing macros to check the return codes and then throw an exception on failure
"development quickly turns into a game of code- and file-system navigation rather than programming and code editing"
You would rather have to code everything from scratch than spend a bit of time (with IDE assistance) finding what module does what you want? Good luck with that.
Is this guy calling for us to go back to the day when everything was dumped in the main function of a C program? Yes modularity is a pain but it is a bigger pain having to try to figure out how to do everything from scratch every time you start a new project. It is like an architect complaining about a house being made out of a whole lot of bricks rather than as a whole wall at a time. Sure you "could" do that but then you'd have the little problem of getting the wall to the job site and getting it vertical (similar to the size of the dll loaded in and difficulty of grasping in coding land).
Have you tried Vrapper?.
It integrates very well with Eclipse as it's implemented as a filter that runs over any text editor, so it does not interfere with any eclipse functionality. Not all vim functionality is implemented yet but the most common stuff is there.
Well, there's multiple levels of abstraction in any applied science, and you've chosen your preferred "base" level. But remember that people like the guys behind from NAND to Tetris don't feel that your level of abstraction is the correct base either. But they've chosen a base level of their own that they define as "computer science" beyond which there is only "physics".
Lower levels of abstraction are good for building up background knowledge, but how deep you go really should depend on what your audience is expected to produce.
Although I would guess from your description that these aren't potential devs, just people "toying" with code, so they shouldn't be dealing in anything big enough to require an IDE anyway...
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
I use VS 2010 and have been using the VS series since 2003. I find it to be a great step forward. Add source control and you have a real production environment. Coding without and IDE would be like using a hand drill instead of a power drill, it just doesn't make sense.
In most languages you don't need a debugger for stuff like null pointers; perfectly fine exceptions are thrown and reported telling you exactly what you did wrong. When is the last time you ever used a debugger to track down such a bug? You use debuggers to analyse why some algorithm isn't worked as it's supposed to; for finding flaws in human thinking.
I'm thinking you've never worked on a multi-threaded application with millions of lines of code. With a debugger, set an exception breakpoint and you can usually see exactly why something bad happened with almost no time wasted on "analysis". If I can reproduce a problem in a debugger I can usually fic it about 10x faster and more reliably than if all I have is a stack trace.
XML is a known as a key material required to create SMD: Software of Mass Destruction
Another effect of the bloated syntax of Java is that it is unsuitable for teaching or learning programming, as learners will struggle with the language most of the time instead of learning what counts.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
People get really dogmatic about the right and wrong ways of doing software development. Not just old people...nearly all programmers do this.
Such people are not necessarily so dogmatic about everything, however.
I agree on that an IDE debugger is one of it strongest advantages, and it's not fault of the language the need for it.
Nevertheless I don't think debug mode is a good strategy for developing, I think it's better to use TDD, even to resolve bugs, create a test trying to reproduce the error and see the assert failure message or exception message to delimit where the problem is.
Most of the time, in my experience, the problem seems evident looking at the code, if not, I use the debugger while running my test.
Once it's fixed I already have a test case to ensure the bug never happens again.
Butthurt blogger posts something to attract attention to himself. Slashdot obliges.
In my first professional programming job, the chief debugging tool was a stack dump. The run time would literally print the whole of the process stack onto the line printer, using, on average a third of a box of paper. Since this was Burroughs B5000 architecture, that was the whole program state. Of course you'd have to wait an hour for the print to finish and if you ran out of paper or had a jam that was it.
I'll take the debugger every day over exceptions with more information.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Exceptions are intended to be used when a program hits unexpected or fatal issues which cannot be handled locally, and often the low-level library code isn't in a position to be able to judge whether something qualifies as worthy of an exception or whether it's an expected part of the processing cycle and can be safely be ignored.
Exceptions are very much overused and very well misunderstood. They are one form of returning errors with additional information.
Essentially you have several choices on how to return errors:
1. Return and do nothing about it - no information, etc.
2. Return an error code that needs to be looked up for a user-readable string to log and/or display.
3. Generate an exception - which contains an exception type and a user-readable string.
Now #1 is absolutely the worst thing to do as nothing will know about the error. This is kind of what Compaq did with their floppy controllers back in the 1990's - and they ended up in a big lawsuit (and lost) over it. So while it's an option, its not a viable option.
#2 is what the standard C library does. Many OO programmers don't like it because you have to query for the strings, and its more Functional programming in form.
#3 tends to be favored by OO programmers as things are encapulated into objects/structures when the error returns.
But, #3 is also the most abused as programmers tend to handle a few cases, but then just let most of the exceptions fall thru to the caller. Except, typically the caller won't be able to do much about the exception at all because the farther up the stack the exception has to go to get handled, the less ability that the "caller" will have to do anything about it - so #3 tends to become what you describe since the error ends up so far removed from what generated it that nothing can be done even when something could have actually been done in the first frame or two around the actual error. This issue is due to (i) the laziness of the programmers at each frame level, and (ii) the indefiniteness of how to actually handle exceptions.
That is, to handle an exception properly you have to capture every kind of possible exception that could be thrown by the code you are wrapping the in the try block. However, programmers are lazy so they only handle the ones they want to or know about, thus others fall through to next frame up the stack, making the next level that much harder to capture the exceptions on. But this is also the nature of exceptions as each different kind of error can have a different kind of exception - there's an exception for memory errors, for file i/o errors, for general i/o errors, for object recognition errors, and so forth. So once you start using exceptions you start building up tens of different exceptions you have to watch out for.
At least #2 was consistently designed even if not consistently handled - that is, the return code was always the return code and you might have had to check errno as well, but that was about it. Programmers might have not checked the return codes and just directly checked errno, or they might not have done that at all; but it was generally a lot simpler to track down and how hard it was was dependent on how lazy you were when you wrote the code.
Take for example asking to open a file for reading and the file not being available for some reason. If I'm just copying a large directory structure then I can reasonably expect to not be able to open a few files due to permissions and, while I'll likely want to log these and display them, treating it as an exception wouldn't be suitable. If my code is part of an online application and it was failing to open a configuration file which it needed to connect to the database then the error would be worthy of promoting to an exception if it could not rectified in the code which detected it. Ultimately though for this type of 'It could be serious, it could be nothing' then the decision should be lef
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
'we end up with lots and lots of small files for every interface and class in our system. On any less than trivial Java system, development quickly turns into a game of code- and file-system navigation rather than programming and code editing. This nature of Java development requires IDEs to become navigation tools above all.
Hallelujah!
Let freedom ring from MS Windows' all versions.
Let freedom ring from OS X.
Let freedom ring from every cell phone and mobile device.
From every unix and linux variant, let freedom ring.
And when this happens, when we allow freedom ring, when we let it ring from every cubicle and every laptop, from every text editor and every console, we will be able to speed up that day when all of God's children, scripting men and compiled code men, coders and computer scientists, professionals and students, will be able to join hands and sing in the words of the old Negro spiritual:
Free at last! Free at last!
Thank God Almighty, we are free at last!
the standard library has a tendency to return null when something goes wrong rather than throw an exception
This is because they were trying to get rid of the code smell of there being too many throws on one method.
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well. They will oscillate in how much they get used in other areas - and in full application development - as people try other things (e.g. D, Java, C#); but will never actually go away.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
I have used IDEs (IDEA, Eclipse, and Xcode) and text editors (Vi and Emacs) on large scale projects with teams both elite and ordinary. I have been productive with them all, and have found each approach to have its own benefits. A lot of modern programmers have not walked a mile in non-IDE land, and have turned the advantages of IDEs into compulsory requirements with which to judge the manual/small tools aproach an automatic failure. They can be broadly categorized as integrated tools, code generation, and autocomplete. Each is a good thing, but is not always the One True Answer.
1. IDEs have integrated build/debug/test/etc.
Staying in the IDE to perform those functions is nice, though switching to another tool in another window is also fine. Having it in the same UI means you don't have to switch mental context to a different UI style, but having smaller, purpose-built tools for specialized tasks also has advantages.
2. IDEs have code generation and refactoring built in.
This is a good feature for getting today's code out quickly, but manual approaches can aid long-term system improvement. Using a boilerplate solution foregoes an opportunity to consider subtly different approaches and may lead to "every problem looks like a nail." Automated refactoring means you are not looking at the callers to understand their intent. These things work well most of the time and get code in front of the customer without wasting time on typo management or gold plating, but spending more time considering new and existing code can lead to a more robust system.
3. IDEs have autocomplete.
Similar to item 2, this saves wasted time looking through source code or documentation, but may cost opportunities for debugging or improvement. For calls to internal code, not having autocomplete essentially inlines code review, and automatically focuses the most review on the most heavily used methods. Whether calling an external library or internal code, manual lookup gives the opportunity to see what else is available in a library or class. As with code generation, autocomplete saves time at the expense of opportunities for discovery.
IDEs are excellent tools, and IDE-oriented programming is very effective. More manual programming and using smaller tools also has advantages. To suggest that either method -- like any one language -- is the One True Way to program proves little more than one's lack of imagination.
Stop-Prism.org: Opt Out of Surveillance
I've done programming both with and without IDEs (starting with BASIC on ye olde Apple ][). One of my previous jobs involved a huge, antiquated software system written in Ada and running on Solaris 8. The IDE we were provided, Rational APEX, was so horrid that I just stuck to vi (no, they would not let us install vim), gnat, and gdb. It was totally fine. Ada has its quirks, but it is actually a well designed language.
My current job, my first job using Java, has me using Java, spring, hibernate, et al., on Windows with Eclipse and I wouldn't want to work without the IDE. The language and frameworks practically require it. Even though Eclipse is infuriating....
Oh fuck, edlin...
You are giving your age away if you even know what edlin is - worse if you actually used the bloody thing.
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well
What would that niche be, exactly? Time and time again I hear people say that C or C++ is the best language for some situation, but I am not really sure what that situation is. There are low-level languages that do not have so many kinds of undefined behavior and which are easier to formally analyze. There are certainly high-level languages that beat C and C++. CL-PPCRE is twice as fast as libpcre, and high level languages are being used in demanding environments where speed, reliability, and optimal solutions are required (Orbitz, Galois inc., various banking and investment companies' analysis tools, DART, etc.).
So what is that compelling reason to keep writing C and C++ code? Legacy code is all that comes to mind, and all it will take is a major shift in how computers are used to wipe away most of that legacy code. There is a reason that most software is not written in assembly language (and outside of a few very specific cases, hand-rolled assembly tends to be slower than what a compiler produces). That is the same reason that C and C++ will be in the same bucket as COBOL in the future. It is going to be far too difficult to use C, C++, Java, etc. express solutions to the big software problems we'll be solving over the next decade, and it is going to be even harder to express efficient solutions to those problems (in both the running time and optimal solution sense).
Palm trees and 8
Eclipse is a tool, just learn to customize it so it works the way it should. Don't blame Eclipse because there are lousy programmers or because you dont know how to manage the preferences.
> if you've used VS - there's no reason to use anything else.
Yes there is. IntelliJ IDEA is amazing. (Also, getting better: Preview "Kotlin" for instance.)
The belief that "the only real IDE is Eclipse" is just plain false. There are a number of fairly good IDEs for Java. (NetBeans, etc.) If you haven't actually tried them for a while, you don't know what you're missing.
For instance, if you think Eclipse sucks, try IntelliJ IDEA. Eclipse copied a lot of its most popular features from IDEA, frequently fairly badly and years after the fact. There is a freeware version available.
I use both (Eclipse at work, IDEA at home) and I much prefer IDEA.
Typical comment of someone that never used Visual Studio. You don't know an IDE if you have not tried VS
The subject says it all.
My productivity increased dramatically when I started using Eclipse instead of jEdit, and I don't even use most of Eclipse's features. Code completion alone saves a huge amount of time that would otherwise be spent typing long identifiers or looking up identifiers I can't quite remember. And yes, a large part of Java development is navigating around a project. For that, Eclipse's package explorer and outline view are a vast improvement on a general-purpose file manager and text editor.
Most of programming debate that circle around IDE/Static Types seems to have one common cause: The scale of the programming in question.
Projects that needs in order of 10K lines of code really benefit from simple tools. The code size is small enough that you can manage it without using any tools at all. No type checking, no IDE, little documentation.
Projects that need in order of 100K lines of code or more really benefit from complex tools--better refactoring (not just variable renaming, but things like deriving interfaces and abstract classes), instant type checking, discipline in consistency, etc.
It's the difference between building a house vs building a 10 story building. This article is like someone who's only built houses wonders why a 20 story buildng need a team of inspection engineers with CAD printouts.
In Soviet Russia, articles before post read *you*!
I found Visual Studio to be lacking compared to Eclipse. When you factor in the cost and portability concerns, I don't know why anyone (except maybe a Windows-only programmer) would choose Visual Studio.
We're not? I still debug core dumps and use gdb and sometimes vi.
However, once you've gotten rid of all your null objects you will suddenly discover that there's a new most common bug. Get rid of that one and there's another, etc. Pretty soon you end up realizing that you still need a debugger because sometimes the code does not work they way you expected and it fails to work in ways that the compiler can not automatically figure out for you. Guess what, the hardware registers are at the wrong address, the packet was sent in the wrong endian format, the algorithm just doesn't do the right thing mathematically, etc.
Let's just say that however flawless the language, you will still make countless simple mistakes in *logic* that will be an order of magnitude quicker to diagnose and fix with an integrated debugger than with any non interactive means (logging, exception stack traces, command line debuggers).
I remember when /. article titles were not intentionally misleading. I miss those days.
If what you really mean is that everybody should use lisp-like languages then just say so.
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well
What would that niche be, exactly? Time and time again I hear people say that C or C++ is the best language for some situation, but I am not really sure what that situation is. There are low-level languages that do not have so many kinds of undefined behavior and which are easier to formally analyze. There are certainly high-level languages that beat C and C++. CL-PPCRE is twice as fast as libpcre, and high level languages are being used in demanding environments where speed, reliability, and optimal solutions are required (Orbitz, Galois inc., various banking and investment companies' analysis tools, DART, etc.).
So what is that compelling reason to keep writing C and C++ code? Legacy code is all that comes to mind, and all it will take is a major shift in how computers are used to wipe away most of that legacy code. There is a reason that most software is not written in assembly language (and outside of a few very specific cases, hand-rolled assembly tends to be slower than what a compiler produces).
Embedded environments, systems development, OS development, to name just a few.
Most High Level Languages don't like it when a pointer is set to ZERO (aka NULL), yet there are some situations where that is a valid pointer, typically in the kernel. For example, the Interrupt Table on all modes of the x86 processor family (e.g. 8-bit, 16-bit, 32-bit, 64-bit) is stored at address 0x0; if you need to reference the interrupt table then you need to use a pointer that validly points to that address. If you cannot reference such a pointer then the language is useless for that kind of development - e.g. OS Kernel Development, Device Driver Development, etc.
Yes, one could write assembly to manage those gaps, but why when there is no need to? (Yes, the Linux Kernel uses C code for those things IIRC.)
That is the same reason that C and C++ will be in the same bucket as COBOL in the future. It is going to be far too difficult to use C, C++, Java, etc. express solutions to the big software problems we'll be solving over the next decade, and it is going to be even harder to express efficient solutions to those problems (in both the running time and optimal solution sense).
People have been saying that for a long time and it simply hasn't come to fruition; yet it is the ambiguities within C/C++ that allows it to continue to meet the needs.
Language developers have tried to lock down languages, eliminating ambiguities only to have those language relegated to small niches in the market since they are not flexible enough for most application development. Comparatively C/C++ have continued to been used for a majority of application development precisely because you can utilize the ambiguities in the languages to achieve some remarkable things that the language developers couldn't have thought of at the time.
It's kind of like War. You maintain a strong centralized command, and no one under you knows what to do when their superior officer is taken out by the enemy; or you play like the European contingents did in the 1700's and 1800's and do line formations where you just shoot at each other until one side doesn't have enough people and then you charge them, following the rules of War without any thought to what you're doing - and not even trying to protect yourself against the enemy. Or you utilize a highly decentralized command where each unit knows its goals, and the general big picture; and is fully charged with them and given the power to do what they want to achieve it - the officer is taken out and someone else steps up to take charge.
All the languages that try to lock down how things are done are like the highly centralized military armies following the first two examples. They'll do well as long
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
C++, Java, etc. express solutions to the big software problems we'll be solving over the next decade, and it is going to be even harder to express efficient solutions to those problems
I think you fail to understand how adaptable C and C++ is (not java). The strong point isn't how great it is at any given benchmark, but rather how good it is for solving a whole range of different problems. From low level bit banging, to heavy parallel transaction management (how many databases are written in C). Many of the C/C++ "problems" are really more reflections on the lack of standardized libraries for doing things. There are C/C++ libraries for doing everything you can imagine, but you don't have to use them. If your OS provides mmap and its 10x faster than doing read/write style ops then you have that choice. If you want to interface to lua, opencl, or even inline assembly, then you can do it with ease. Just try doing GPGPU programming in a those languages you list. If speed is an issue your application is going to fail, when your competitor figures out how to use a GPU to solve a problem at 10x the rate of a CPU, and your stuck two layers away from the hardware because its more convenient to do regex processing there than picking a high performance one (http://code.google.com/p/re2/) for C++.
The bottom line is that its rare to find a 100% C or C++ project these days. No one writes whole web apps with C++ CGI/bin files, rather using php/ruby/etc. But when you need to operate on a 100GB sparse matrix, you drop to something that can control the access patterns or utilize some hardware specific feature that gives a big performance boost. This is the problem I see with java programmers all the time, a lot of high performance computing is actually "just an exercise in caching", and when you can't control low level details like memory placement a lot of performance tends to evaporate. Even at the big web companies its not unusual to find C++ running some portion of the system where the language du jour failed.
BTW: Even Yahoo replaced their lisp
The OP actually glanced off what I consider a big issue with modern IDEs. Especially for over-engineered projects, there is a clear need to be able to view files that change together, grouped together, regardless of how the Separation of Concerns has been implemented. The idea of using the file system as organizer needs to die. Code is data and should get the support a real database makes possible.
Smalltalk has a built in IDE. Check out http://www.pharo-project.org/home
Perspective is to Science what Interpretation is to Religion. Obama + Paul FTW
People are totally missing the point of TFA.
It's really pathetic to see all these clueless Eclipse / IntelliJ / NetBeans / Visual Studio devs with mod points relentlessly modding up every single pointless comment here that did entirely miss TFA.
If IDEs are so great, why did Linus write Linux using picoEmacs? Why did Rich Hickey create Clojure using Emacs? Why did Rich Hickey create, in a heartbeat, the amazing DB that Datomic is using Emacs? There are countless examples of amazing programmers who created great things using Emacs / vim / Sublime (apparently particularly well-loved amongst the startup crowd), or much more obscure editors (like weird expensive Lisp editors).
The point of TFA is that if you *need* an IDE it means that your language may very well smell. I realize most of you are stuck in C#/Java + Hibernate/NHibernate + XML + Spring hell. And, indeed, when you're stuck on such a pointless career path, you may as well use an IDE to be "productive".
That's precisely the point of TFA: your language may very well be sucking big times if you really need an IDE to be "productive".
As Rich Hickey said: "Patterns means 'I've run out of language".
One of the main point of IDEs is to be able to automate pattern-related tasks ("Refactor : replace inheritance with composition" and whatnots) and it's not that the IDE is bad at this: the point of TFA is that there may be languages out there where these "design patterns" have no meaning and where, hence, these IDEs doesn't make much sense.
At least that's how I get TFA.
As a last point it's really totally really ridiculous to think that Emacs / vim cannot do code navigation for verbose language like C# / Java: not only they can, but they can also connect to Eclipse running in server-mode (using 'eclim') and use the very exact same code navigation features that Eclipse offer (because they're, well, precisely done by Eclipse when you're using eclim).
If you still *think* you're being productive in your Java + Spring + XML + Hibernate hell using IntelliJ (or Eclipse), I'd really suggest watching a few of Rich Hickey's videos. During the years you've been working on one or two enterprisey apps doing really not much (really, been there done that), the guy created a freacking language and then went on to use that language to create an amazing DB. This should give you some food for thoughts.
Most High Level Languages don't like it when a pointer is set to ZERO (aka NULL), yet there are some situations where that is a valid pointer, typically in the kernel
Like I said, there are better low-level languages than C, but that aside, where did you get the idea that there is no way to deal with such a thing in a high-level language? There have been kernels written in Ada and Lisp. The only difference is that in a high-level language, you need to be very explicit about the fact that you want to use a numeric value as a pointer to be dereferenced. The Lisp compiler I use, for example, would allow an address "0" to be specified like this:
This is not to say that you are going to start writing Linux kernel modules in Lisp. I doubt that you'll see many Lisp OSes going forward, but the facility mentioned above is not very hard to write for a high-level language. The advantage is in dependability -- there are fewer ways for this code to do something unexpected than there are in C, especially as the size of the codebase increases (since you would not be using such low level pointers everywhere, there would be fewer ways for a bug to corrupt things). As for speed, here is how SBCL compiles a function that uses this facility (with type hinting):
Not so slow. In fact, most of what that disassembly is doing is converting from/to "fixnum" types (which use low-order bits as flags); this could be further improved by using the facility exclusively, rather than using fixnum types, and thus avoiding the conversions entirely.
Language developers have tried to lock down languages, eliminating ambiguities only to have those language relegated to small niches in the market since they are not flexible enough for most application development
What are you talking about? Do you think SPARK, the well-defined subset of Ada developed by Praxis HIS, is limited to any particular market? Do you think Lisp is? Haskell? ML?
Yes, there are high-level languages that are limited in scope. Prolog, for example, is limited to a particular subset of problems. Yet for the most part, high level languages can either do everything C/C++ can do, or else can do everything C/C++ can do if there is some small extension similar to the one I mentioned above (and really, that extension involves three special forms: one to create a pointer, one to dereference a pointer, and one to compare pointers for equality).
On the other hand, C and C++ are limited by their own inflexibility and lack of high-level features. Try writing a REPL for C++, and see how well that works for you. Try writing something like CL-PPCRE -- a library which reads a regular expression, then compiles a function that matches that expression without having to traverse an expensive pointer structure (the way the C implementation
Palm trees and 8
I think you fail to understand how adaptable C and C++ is
I don't. My first programming language was C++, and I programmed in C++ professionally. C++ is severely lacking in expressiveness, and there is an abundance of undefined behavior in C++. Debugging a C++ program is as much about low-level program mechanics as it is about high-level logic (even when you are writing a high level application). Dealing with errors in C++ is a giant ball of confusion -- there isn't even a good way to deal with errors that occur in constructors or destructors.
C++ is surviving because of its history -- a lot of C++ code was written in the 90s, and nobody has the time to rewrite any of it (not even to get it up to date with modern C++ standards -- I was once on a project that had to use a subset of C++ in order to maintain compatibility with old compilers from the early 90s). Schools keep teaching C++ because they believe their job is to prepare students for jobs in industry where they will be writing C++ code, which helps to keep C++ afloat by training programmers to think in C++. There is no real technical advantage that C++ has -- none of its features are unique, nor is the combination of its features -- and it carries plenty of technical disadvantages compared to other languages.
The strong point isn't how great it is at any given benchmark, but rather how good it is for solving a whole range of different problems
There are other languages that are good at solving problems in that range, which do not have C++'s deficiencies. If you are writing low-level code, do you really want to be dealing with implicit function calls? If you are writing high-level code, do you really want to spend your time deciding between shared_ptr and weak_ptr? If lives depend on your code, do you really want to have no idea about the order in which functions will be called?
If your OS provides mmap and its 10x faster than doing read/write style ops then you have that choice
What makes C/C++ special here? A typical FFI in a high level language let's you call functions in shared libraries (and by extension, functions that your OS provides), and many implementations of high-level languages have (non-portable) extensions for a particular target OS.
If you want to interface to lua, opencl, or even inline assembly, then you can do it with ease
OK, but what if I want to embed Lua in my C++ program, so that I can provide my users with an extension language? What if I want to write Lua code, have it translated to C++ and then compiled by my C++ compiler?
For what it's worth, it is possible to write inline assembly using non-standard extensions in some high-level languages. As for opencl, note that parallel computing in high level languages is not exactly novel -- side-effect free programs have a long history of automatic parallelization.
Just try doing GPGPU programming in a those languages you list
Sure:
http://www.cliki.net/cl-gpu
Really, there is nothing special about C or C++ that makes it better suited for parallel programming than any other general-purpose language. CUDA being written in C++ has nothing to do with any sort of technical advantage C++ has; C++ is well known among Nvidia's target market and the OSes that Nvidia targeted have C or C++ APIs. If we still had Lisp machines and Nvidia was targeting those, Cuda would have been written in Lisp. If the API for Linux were in ocaml, Cuda would have been written in ocaml.
If speed is an issue your application is going to fail, when your competitor figures out how to use a GPU to solve a problem at 10x the rate of a CPU
Well, we've seen that situation before. Orbitz was competing against hand-optimized and tuned code running on mainframes, which have lots
Palm trees and 8
And this is why I hate Java programmers: the idea that puking a stack trace into the logs is perfectly fine diagnostics.
As someone who has to admin large java-based systems, I have one thing to say to that: Go die in a fire.
Mart
"I know I will be modded down for this": where's the option '-1, Asking for it'?
It is ironic to reference a dialect of Lisp, Clojure, in an argument against development environments.
Many Lisp's tightly integrated and pioneered the precursors to modern IDE's. Lisps developed by MIT camp (CADR, LMI, Symbolics and Xerox (D-machines) were deeply intertwined with the pre-cursors to modern IDE's. This was followed by Lucid, Franz, Allegro, and others. The functionality of these systems were ahead of their time and had jaw dropping functionality just as bitmap displays were coming into viability.
Simple syntax or not, good development tools amplify a good developer. Opinionated developers debate tools, emacs versus vi, and spaces versus tabs. Bad tools and bad developers....
Im a gdb, coredump and vi guy.
When I ran into the need for dynamic programming (REPL), I integrated a compiler into the C product that noticed when I saved source code file, compiled it and replaced the function within my real C program. When I'm finnished with that module, I remove it from the list of hot compile entries and let it get compiled and optimiezed by the offline compiler.
Who sais you cant do "advanced-stuff" with "old languages", using IDE and JRebel is in a way a statement of "I dont want to learn how it works, I just want it to work". Nothing wrong with that, until it doesnt work. I'm sure I would be much better of finding the bugs when that happens.
That's why I hate retarded douche-bags who can't be bothered to read the context. The parent was talking about finding root causes of null pointers. I pointed out that if errors are properly logged the stack trace would include the "caused by". So why don't you do the world a favor and eat shit and die.
I've always liked Scite http://www.scintilla.org/SciTE.html since I first started scripting and coding. Very very light and fast, has syntax highlighting for most languages, multiple tabs, search and replace, and can compile though I always do that from the command line. Not that anyone cares, just felt like saying so.
Try writing a REPL for C++, and see how well that works for you.
I've done that quite a bit in both C and C++ without issues - and I'm not talking about doing things using toolkits such as Gtk, Qt, MFC, etc. Then again, I'm more a fan of Defensive Programming and Secure Programming...
The difference is that the solutions written in high-level languages are fast, closer to optimal (or actually optimal), and will not bog programmers down with debugging low-level pointer mechanics.
Any time I hear this argument, I know the writer/commentator is usually full of it. Namely because no matter what language you use, you'll end up with those kinds of issues in some form. It's just a matter of how easy it is to actually do something about it or even diagnose that that is the issue.
Comparatively C/C++ have continued to been used for a majority of application development
Which has more to do with the fact that most popular OSes are written in C or C++, and have APIs and documentation written for those languages.
It has nothing to do with that. You can interface any language to any OS regardless of the API and documentation. It's done by defining to the language the interface in a way that both understand and agree on - sometimes requiring intermediate steps to make the switch. But it is not impossible. The Windows API actually has numerous calls that use the PASCAL calling convention as opposed to the C Calling convention; yet that does not prevent people from using those APIs in C, C++, C#, Visual Basic, or number of other languages.
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Were it not for these historical realities, C and C++ would already be an obscure, legacy languages like COBOL, comfortably placed at the tail end of jokes told on sites like Slashdot. C and C++ are "good enough" languages -- just good enough to accomplish what their creators and users are trying to do, but still inferior as languages.
C, and its extentions C++ and object-C, have withstood history because they have met and exceeded their target goals. They were designed as systems languages - designed for doing operating systems and systems applications, and that design continues to match the needs of that field. Their design also enables them to exceed being simply relegated to systems and build the rest of the user experience as well. It's little wonder that they are there and are still around. It only amazes the people who don't have much clue about systems programming.
I am Lisp programmer
That explains a lot. Lisp is like writing for the Obfuscated C contest in everything you do. It serves little to no purpose in real world computing, code maintainance, etc. Yes, it serves a purpose for some fields and does that well, but that's it.
So what is C++ doing that is so special? What are you doing with templates that even compares to Lisp metaprogramming? Where are the programming languages being embedded in C++? It takes a new C++ compiler to get a simple feature like lexical closures in C++; yet it is possible to implement a completely new Lisp dialect using only macros in an existing Lisp, without requiring a new Lisp compiler (e.g. Qi).
Lisp, as you note, is a meta programmer - more akin to Java and Smalltalk in that it runs in a virtual machine. Like SmallTalk the language itself defines the virtual machine so writing a new function extends the functionality of the VM and thereby the language. The nature of the virtual machine itself is a simple interpreter - like running JavaScript in a web browser with the V8 engine. However, these very features - the v
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
This is completely wrong. I happen to use a vim setup without any heavy duty IDE, but there are definitely valid use cases for a good debugger. The best example is diving into an unfamiliar code base. Sure, if you wrote the code, you should rarely need a debugger, but when the guy who got fired down the hall dumps all of his crap code on you when he leaves, a debugger can be a real lifesaver.
Separating objects into classes and interfaces and forcing each into it's own file helps in the organization of the code. IDE's make that implementation practical. Programmers who don't like that shouldn't use Java, but to cite that as one of Java's flaws is ridiculous. Java has no shortage of flaws, but that is most certainly not one of them.
IDE's enable a lot of nice things, auto-complete that makes like long descriptive variable/class names a breeze to use. Descriptive variable/class names enhance the readability of code. One thing programmers often forget is that programming is not just about informing a computer about what you want it to do, but also informing programmers reading your code what your want the computer to do. The first part is actually the easy part, it's that second part where most programmers tend to fall flat on their faces. Readable code is a good thing, it reduces human error which is the source of all programming bugs.
IDE's like anything can be misused, but the idea that everything must be VIM friendly is nonesense.
I think you shouldn't put too much stock in your own reading ability; you admit that you puke stack traces into the log. Do you know how hard it is to actually diagnose anything when your log is full of stack traces?
Of course you don't. You're a Java Monkey, a lifeform only marginally more intelligent than the PHP Ape.
Mart
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Well,
Unless you are programming "total object oriented", languages lik e"C" and arguably c++ can benefit greatly from an IDE. Particularlly if context esensitive help, and debuggers are included.
Come to think of it, I can't think of any case "besides learning in school" that a person would use notepad or similar to write code "quickly" or "efficiently".
Borland set the standard years ago for this environment with Borland C and Borland C++. blew everything else away with productivity increases.
Microsoft's answer was Microsoft C Compiler and the junky editor that it had. Paled in comparison to Borland.
I code mostly in C and C++ but I sometimes use other languages too. I worked in many environments, with or without IDEs and I am surprised how little difference it made in actual productivity.
Features such as auto-completion, fast documentation and definition lookup, integrated debugger, compile error highlighting, etc... are all useful and I use them extensively when I am on an IDE. But even with perfect tools, I can't code faster than I can think, so as long as I am familiar with my environment and it is not completely broken, the gain is minimal.
Namely because no matter what language you use, you'll end up with those kinds of issues in some form
Except that in some languages, those issues are rare. The only time I have seen a Lisp program corrupt its heap (through the equivalent of a dangling pointer) was when I explicitly disabled safety features. In C and C++, on the other hand, dangling pointers are a common and routine source of problems; in C++ especially, dangling pointers tend to creep up in all sorts of unexpected ways.
That is why I said programmers will not get bogged down with these problems -- these sorts of things are sufficiently rare in high level languages that many programmers will not see them.
You can interface any language to any OS regardless of the API and documentation
Only if your language has a suitable FFI or if interfacing with an OS is actually a language feature. Some high level languages do not have such an FFI, and in many high level languages the FFI is cumbersome to use. OS documentation usually assumes the programmer will be using the same language that the API is written for (nothing else would make sense), which adds yet another hurdle for programmers using another language.
I am not saying that it is impossible, I am saying that it is harder to do and that there is an advantage to using the same language that the OS was written in. OSes have been written in Lisp in the past -- and unsurprisingly, most of the applications for those OSes was also written in Lisp (as opposed to some ML, Ada, or C++).
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Except that C++ doesn't limit undefined behavior to situations that make sense -- for example, converting from a numeric type to a pointer type (this may not make sense on all architectures, but it does make sense on some). In C++, you have undefined behavior that could not possibly make sense no matter what architecture you are using. In what system does it make sense to allow control flow to reach the of a non-void function? In what system does it make sense to allow a reference (which cannot be reassigned) to a local variable to be returned from a function? These are things that could have been forbidden by the language definition; instead, it is up to compiler writers to decide what to do, and the fact that pretty much every compiler has had non-standard features for detecting / rejecting such things had no impact on the C++11 standard.
These are not features that add to the flexibility of C++; they are just traps waiting to ensnare novice programmers.
It is hard to argue that C++ is a flexible language when you need a new compiler just to add a feature like lexical closures. If you want metaobject protocol, continuations, or other language features, you are either stuck with some clunky, brittle, and inefficient version using templates and operator overloading or else you are going to need a new compiler (and then you can forget portability).
C, and its extentions C++ and object-C, have withstood history because they have met and exceeded their target goals.
First of all, C and C++ have both been updated several times in order to remain relevant. Second, saying that C exceeded the goals that its designers had in mind is not saying much -- the original Unix is not very impressive, even by the standard of the 1970s. Neither is saying that C++ exceeded its designer's goal: C with objected oriented features (that goal was expanded to "a language that is relevant" -- and C++ has not exceeded that goal, it has only met it adequately for most programmers).
As for objective C, it was hardly a blip on the radar until Apple gave it a boost. Hardly
Palm trees and 8
This is such a fun topic, but it makes me glad that most of my programming is math and stats and I can leave the GUI and interfaces programming to better and more tightly wound coders than I. All I ask is that the mouse cursor not make me curse, the touchpad interface not make me touchy and the help files all be accessible through Google.
"There is no god but allah" - well, they got it half right.
Have you tried Emacs? It is my favorite operating system. Sure the text editor is a bit weak, but overall it totally rocks!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
You're a fucken inbred retard. Go back to your cave you whiny crybaby.
C++ is severely lacking in expressiveness, and there is an abundance of undefined behavior in C++. Debugging a C++ program is as much about low-level program mechanics as it is about high-level logic (even when you are writing a high level application). Dealing with errors in C++ is a giant ball of confusion -- there isn't even a good way to deal with errors that occur in constructors or destructors.
C++ lacking in expressiveness? You have got to be joking, your right there are a lot of poorly defined areas in C++, but many of them stem from the fact that there are 100 different ways syntactically to solve any given problem. Of course some ways tend to be better than others, hence I'm confused about your problems with constructor error handling. You handle errors in constructors with "throw", combined with good RAII style, you get the benefit of fast code, that is robust to memory errors. Destructors aren't as clear cut, but the easy answer is not to have fatal errors in the destructor, rather pulling a java and using them more like finalize.
One of C++'s strong points (vs C) is that you can create a domain specific environment by careful class design and operator overloading. For example our database access library allows you to access a row's column similarly to the same way you might do it in some other languages with first class associative arrays. 'if (result_row["column_name"]==somevalue)' because it overrode the brackets operator. Similarly I have a big num library that operates transparently with all the built in numeric types, even going so far as to work with a template matrix library I have.
As far as debug-ability, or a programmers ability to focus on the problem at had rather than the language, I suspect that is all just a matter of experience. I've written some extremely complex algorithms in C++ over the last couple years. Not once have I had the need to do anything more complex than display some variables, or a datastructure after some portion of the alogorthm has completed. Maybe what your are describing here is more what I call C++ inverted learning curve. In a lot of languages you learn how to do things, in C++ you tend to learn how _NOT_ to do things. Get to much of this in your project it starts to fail in ways that are beyond the skills of the authors. This happens in other languages too, just in different ways.
What makes C/C++ special here? A typical FFI in a high level language let's you call functions in shared libraries
Because its horribly inefficient in most interpreted or GC languages. Time and time again, what you see in the "thunk" layers are pieces of code copying data from some language specific data structure/layout to the one defined by the native call. Or worse yet, you see giant global locks synchronizing all the other application threads. I spoke of mmap() in my earlier post. mmap() is one of those functions that can literally provide orders of magnitude performance boosts (vs explicit read()/write() type calls) in applications that are disk IO (for reasons that take a while to explain) intensive. Yet few languages outside of the C/C++/etc style languages even support it.
Well, we've seen that situation before. Orbitz was competing against hand-optimized and tuned code running on mainframes, which have lots of hardware acceleration, and speed is crucial.
Hardware acceleration to do IO, which is also "hardware accelerated" in any x86 server since about the mid 90's when IO adapters started having their own RISC processors, and mostly doing scatter/gather DMA. I have a (brand new!) mainframe, trust me if your application can't beat the pants off a mainframe running on midrange server, then your code is shit. But in a way this proves a point about efficiency. I've seen it a number of times, someone comes in and tries to replace a few hundred KLOC of COBOL, with some "newfangled" language (likely java). The end result requires a cluster of 20 PC's, consumes 10x the memory, and runs 1/2 as fast. This is why/how IBM continu
eclipse display window provides a repl interface to java in the current stack frame.
I find debuggers useful for catching library and compiler bugs.... but other than that... a waste of time.
See, the reason I know I'm an actual human being and you're nothing but a poo-flinging baboon, is that I actually gave some arguments along with the invective.
Once again you show that most Java Monkeys cannot do anything but blindly regurgitate.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
C++ lacking in expressiveness? You have got to be joking,
Well, how might you add "operator#" to C++? Adding new language features to C++ basically requires a new C++ compiler; lexical closures, for example, only became possible with C++11 (previously, Boost's lambda expressions library got you halfway there). That is a result of a lack of expressive power.
your right there are a lot of poorly defined areas in C++, but many of them stem from the fact that there are 100 different ways syntactically to solve any given problem.
It is mostly due to the standard being written for compiler writers and language implementors, rather than for programmers.
Of course some ways tend to be better than others, hence I'm confused about your problems with constructor error handling. You handle errors in constructors with "throw", combined with good RAII style, you get the benefit of fast code, that is robust to memory errors
Except when your objects are global, in which case throwing the exception means your program aborts, since there is no standard way to write a global catch (set_terminate won't work if the exception is thrown before the entry to main -- which is what will happen if the constructor of a global object throws the exception).
Destructors aren't as clear cut, but the easy answer is not to have fatal errors in the destructor
In other words, destructors should have trivial bodies. Why even have destructors if that is how things have to be done?
One of C++'s strong points (vs C) is that you can create a domain specific environment by careful class design and operator overloading
Unless you want to add a new kind of operator or a new kind of syntax.
As far as debug-ability, or a programmers ability to focus on the problem at had rather than the language, I suspect that is all just a matter of experience.
In a lot of languages you learn how to do things, in C++ you tend to learn how _NOT_ to do things
Which is precisely the problem here. In C++, you need to know what valid C++ expressions, statements, or programs should simply not be written. Rather than rule such things out in C++11, the standards committee just added more things that you are supposed to know not to do.
Those results have re2, and it beats all the normal regular expression parsers only loosing to a lisp specific parsing/matching system. I don't call that a win for LISP, if you move the goal posts (we were comparing regex) then its not apples to apples. Its not hard to imaging a dozen ways of creating a searching sorting system faster than regex if your willing to wiggle the requirements.
Like I said, this is not a good benchmark; on the other hand, RE2 is not average twice the speed of libpcre (unless you count an outlier):
http://lh3lh3.users.sourceforge.net/reb.shtml
CL-PPCRE does average twice the speed of libpcre/Perl (unless you pick examples that libpcre can handle well):
http://cl-debian.alioth.debian.org/repository/rvb/cl-ppcre-sarge/doc/#bench
I would not draw too many conclusions from the benchmarks alone (there is no direct comparison between CL-PPCRE and RE2), but CL-PPCRE does do something that neither libpcre nor RE2 do: it compiles your regex into a callable function that does not traverse a pointer structure. With a good compiler (n
Palm trees and 8
In C and C++, on the other hand, dangling pointers are a common and routine source of problems; in C++ especially, dangling pointers tend to creep up in all sorts of unexpected ways.
Dangling pointers are not nearly as much of an issue in C/C++ development as made out to be. They are an issue for people that don't understand pointers. But I would say that for the majority of C/C++ programmers that are not inexperienced they are not an issue.
You can interface any language to any OS regardless of the API and documentation
Only if your language has a suitable FFI or if interfacing with an OS is actually a language feature. Some high level languages do not have such an FFI, and in many high level languages the FFI is cumbersome to use.
That is an issue of the language you are using, not the language the OS is written in. Thus they are niche use languages.
OS documentation usually assumes the programmer will be using the same language that the API is written for (nothing else would make sense), which adds yet another hurdle for programmers using another language.
If you know how to use documentation that is not a hinderance. Writing Windows Scripts in JavaScript with Windows Scripting Host (WSH) is a pain because the documentation for WSH primarily written for use with VBScript. Yet it is not impossible to use JavaScript, Perl, or Python with WSH - not even very hard; just a bit more painful as you have to figure out a couple things. (Personally I prefer WSH+JS over WSH+VBscript.)
I am not saying that it is impossible, I am saying that it is harder to do and that there is an advantage to using the same language that the OS was written in. OSes have been written in Lisp in the past -- and unsurprisingly, most of the applications for those OSes was also written in Lisp (as opposed to some ML, Ada, or C++).
It's advantage is only in not having to write the Language Bindings for other languages. Many toolkits do that kind of things. It's just a task that has to be done to use languages on top of those OSes.
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Except that C++ doesn't limit undefined behavior to situations that make sense -- for example, converting from a numeric type to a pointer type (this may not make sense on all architectures, but it does make sense on some). In C++, you have undefined behavior that could not possibly make sense no matter what architecture you are using.
Again, it depends on what you are doing. The memset() and memcpy() functions takes a void pointer; would it make sense to write an infinite number of them for each type? No. Yet they are very fast ways to clear and copy data and data references. Misused, they can wreak havoc.
Converesly, C# and even Managed C++ (C++/CLI) which tries to solve problems related to the misuse of functions like memset()/memcpy() makes it very difficult to copy a buffer of data in at least some situations - e.g. sending it to the network. So instead of having a send(), one has to convert the first chunk to a integer and then use pointer arithmetic to copy the whole buffer.
In what system does it make sense to allow control flow to reach the of a non-void function?
You do realize that compilers notify programmers about that?
And of course, there are ways to set up the function so that the return value is there without the compiler really knowing about it - but then you're getting into Obfuscated C territory.
And there are also times when the API changes but you can't really change it - so documentation gets update (hopefully) to matc
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Every bit of efficiency of using my IDE vs. a simple text editor was lost today reading these comments.