Slashdot Mirror
Getting Back To Coding
New submitter rrconan writes I always feel like I'm getting old because of the constant need to learn a new tools to do the same job. At the end of projects, I get the impression that nothing changes — there are no real benefits to the new tools, and the only result is a lot of time wasted learning them instead of doing the work. We discussed this last week with Andrew Binstock's "Just Let Me Code" article, and now he's written a follow-up about reducing tool complexity and focusing on writing code. He says, "Tool vendors have several misperceptions that stand in the way. The first is a long-standing issue, which is 'featuritis': the tendency to create the perception of greater value in upgrades by adding rarely needed features. ... The second misperception is that many tool vendors view the user experience they offer as already pretty darn good. Compared with tools we had 10 years ago or more, UIs have indeed improved significantly. But they have not improved as fast as complexity has increased. And in that gap lies the problem.' Now I understand that what I thought of as "getting old" was really "getting smart."
Write code.
I have an issue with my programmers when they know how to use the tool, but don't understand what they created. I overheard one group discussing a new system, and the one stated she didn't know where the code actually ran. No one in the group did. The Integrated Development Environment hid the details. No wonder people leave gaping security holes in systems if they don't understand how they work. I have really smart people who don't understand how the application server accesses the database. They just write code, and it works. They get used to figuring out how the tool works, not how the system works. If the tool is replaced, they are lost. If required, I'll go fix it in a text editor, because I understand what it's doing. I don't need an IDE to tell me. I know what information is flowing through the system, and how it does it. That way I can prevent inappropriate data from being exposed to outside users. IDE's are very useful to speed development, but you can't base your entire knowledge of programming on how to use a tool.
My development chain starts in the terminal (I program mainly for Linux; your Windows experience may be impossible to adapt to match). I have vim as my editor (and have nothing against people who use emacs). Once in a blue moon I try a GUI editor (like gedit, geany) or an IDE (like Eclipse or Netbeans), and I always find myself going back to vim, because everything else slows me down. My documentation is on the Net. If I need to know something about an API I google it. I don't miss autocomplete very much, as if I know what I want then vim's Control+N suits me very well. If I don't know what I want, then autocomplete will not really solve it for me anyway. I write my own makefiles, and call the auxiliary tools (is a compiler "auxiliary" to editing code?) knowing very well what I want them to do. For version control I also use the command line, because GUI tools never seem to help, and always seem to hinder.
I find myself very productive given that I don't use "productivity enhanced" tools.
What I would very much want is a fucking GUI editor for Android apps, because editing XML files from scratch is getting on my nerves. I don't know what makes it so much more annoying than editing straight up HTML though. Maybe I just didn't familiarize myself the Android GUI XML well enough to use it, but given how easy it is to do things in Xcode for iOS, I think Google need to put some effort into it. I think Xcode is pretty much the only IDE that didn't get in the way when I needed to use it, but I can't use it for more than iOS apps, or on Linux so...
Sounds like we need some Programming, Motherfucker!
Do you speak it?
FTFA "The reason that so many tools have become unwieldy is that they chase after certain values that add complexity but not usefulness to SMB-sized projects"
If the author of the article would just choose his tools more carefully he could have saved himself these weird rants about things that he brings on himself. It's like a bike rider lamenting how uncomfortable his racing bike seat is when he's riding it around the block.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
At the end of projects, I get the impression that nothing changes — there are no real benefits to the new tools, and the only result is a lot of time wasted learning them instead of doing the work.
To be fair, that's because many new techniques and tools are focused on maintenance and not the initial writing of code. It's fairly obvious that you wouldn't see much benefit of things focused on the post-project during the construction of the project.
...Everyone says "I only need 10% of what this word processor will do." Everyone else will agree with that statement. The problem? The 10% I need is not the 10% YOU need.
I find the article strangely short-sighted. Sure, we have to avoid overengineering solutions that are not going to be needed in the near future. But to say "you should not code features that are not immediately needed in the current sprint" will lead, in most cases, to significant rework in the future. Rework is money and time.
A key part of the work of a smart project lead, whether that lead is an active developer or not, is to anticipate the product direction. The lead has to be able to say, "Sure, we're only going to write this subset of functionality *now*, but it is a near certainty that users will want this expansion of it in just a couple of years. We might as well have the basic framework for that in place, even it's only stubs."
Further, our tools are complex because our needs are complex, even at the SMB level. I've been a developer for 30 years now, writing everything from experimental personal-use stuff, to local utilities, to enterprise software that is used by some of the largest manufacturers on the planet. Even small users expect unanticipated cases to work. Big customers expect that, not only do unanticipated cases work, but that migrations to new versions will be tailored to THEIR needs and will happen without notable incident. As but one small example that means that internal testing of a new release not only has to work as a brand new install, but it must also work as an upgrade, and it must work as an upgrade against the specific data and specific customizations (real software is customizable), even when you don't know what those are. If you expect success in that environment, you're going to need a LOT of tools: source code management (to identify what changed when you introduce a regression), an automated testing framework, a way to test builds and build functionality, a framework for testing upgrades against real customer data (that they let you use for this purpose), and then tools and processes that let you track code reviews, approvals, and the like. That's a lot of tools, and a lot of staff to follow it all around.
My organization has some excellent tools, and developers assigned solely to maintain them for the rest of the development staff. It means, though, that any new developer coming in is going to have to learn a lot more than a programming language.
...on how to best create software. It seems really, really tough to get anyone finance-minded in the *business* of making software to understand that it's worthwhile to do exploratory development of tools and techniques to be much more productive later on. There is simply not enough money being invested into making better programming tools. The fact that free, open source software is so pervasive in for-profit companies is proof of that. Everyone would rather take what they can get, squeeze as much money as they can out of it in the near term, and wait around to benefit from everyone elses investments back into the technology.
I'm in systems engineering/administration, so the vast majority of my "coding" experience is focused on automation and scripting. Predictably, stuff like this is very procedural and different from application development. However, the biggest shift I've seen is not really in the complexity of tools, but the shift in focus to gluing together pre-defined parts. Sure, languages have always had standard libraries, but development (especially in the mobile OS or web framework environments) often leaves me trying to figure out how much I would have to code from scratch and how much work has been done for me simply by including Massive Functional Library X. Don't get me wrong, it's a good thing to not have to do everything yourself, but I sometimes wonder how much control one gives up when they just write an app by putting someone else's code together.
One example from my side of the fence is Windows PowerShell. It's amazing, but it really requires a complete shift in thinking if you're used to writing VBScript. JavaScript or batch language automation. With the other languages, you have to write lots of code to parse command output or iterate through a WMI structure. Some of the stuff is so complex that sysadmins who don't really know the under-the-hood workings just cargo cult the whole thing and make a mess. PowerShell became useful to me when I realized I no longer had to write chunks of code solely dedicated to reading the contents of formatted CSV files. Lots of the complexity of that rolls up into a line or two of script. Again, it's not a bad thing, but if you're used to DIY, it makes you wonder how the "magic" is being done. When you move up the stack (iOS, Android, etc.) that abstraction is even more stark...as in, just call this library which handles the entire database-access layer that used to be huge amounts of coding.
The trend was started by Microsoft and Borland in the 80s. Apple bucked the trend by staying w/ C, then C with objects, and now Swift. Java, while a really nice thing to drink, was just an easy version of C++, or an easier version. Visual Basic was popular for years, because it was easy/easier. Microsoft's tools like Visual Studio, are difficult for someone like me that comes from a much easier and productive database environment. COBOL and FORTRAN were early attempt at the language making programming much easier. I was in the business for years, and drawing a screen and creating a database was a snap, compared to what the rest of the world was doing. Then, it gave me a niche to work in.
c/c++, vi/emacs, make, ddd.
Lots of good years of use, likely many more years of usefulness, too.
Uh, Linux geek since 1999.
No criticism of the OP here, but this got me thinking about one of my mortal enemies. The UI within SQL Server Management Studio. For the last decade of upgrades, I've really wondered how that development team leaves the office everyday thinking they are doing a good day's work. There are so many blatantly apparent rough edges to the UI for SSMS, I can't believe they think it's as good as they can make it.
In order to avoid tldr, I'll just give a single example. Look at the tabbing for each database connection window. The tabs are labelled "servername.database" but are limited to a small number of characters regardless of how many tabs are open. Here's an example where there are only two open tabs:
http://img.informer.com/screen...
The first reason the labelling is fundamentally broken is that the database name is chopped off in an unnecessary abbreviation. The tab could stretch out to display the whole thing! It's not scrunched in with a bunch of other tabs. There's plenty of room there.
The second reason this is broken is that the database name is the thing you actually need to see more than the server name. In the majority of use case scenarios, the user is connected to multiple databases on the same server. When switching tabs, you need to be able to locate the one for the database you're looking for within your current connections. Sure, there's that pulldown menu on the left, but that's a much further mouse drag than the tabs are from your focal point.
So, if you're ever looking for an example of a developer interface that doesn't get a proper update, look no further than SQL Server Management Studio. It's hardly changed in over a decade of releases.
$5 / month hosted VPS on linux = awesome!
This advice is what I give people who ask me "how can I learn to program computers like you?"
Build something. Find a problem and solve it. It doesn't matter what the problem is or how you solve it.
Write a tic tac toe engine, or a photo slideshow generator, or a fart joke generator, or whatever you want to do. But you just have to do it.
As a (mostly) hobby programmer I agree. Tool complexity is much too high. Programming languages and widgets toolkits are relatively fine, though (except for intentionally blown up languages like Java). The real problem are the tools for building, packaging and deployment. For example, I was considering to package a cross-platform application I wrote for the Ubuntu "app store" but gave up after studying the in my point of view fairly complicated rules and process. Kudos to all package and repository maintainers, it seems to take more time packaging an application than actually coding it. I also admire anyone who masters the complete GNU toolchain, which, again, seems to require more programming in incomplete domain-specific languages with arcane syntax than writing the program to be built.
I wish I had more time. Busy people like me need tools that allow them to write an application, copy&paste the docs and icon images and produce the executables for all major platforms. Some commercial toolkits come close to that, but unfortunately even those that once have started as affordable shareware have become ridiculously expensive.
However, I'm not convinced that the reason for that state of the art is featuritis. Having the features never hurts, it's the way the tools have to be configured. Too many authors of programming tools do not know or do not seem to care much about ease of usability.
Not just programming tools have usability deficiencies, though. I'm afraid GNU/Linux, which I use daily for work and fun, has similar problems. For example, Ubuntu frequently bothers me with a dialog asking me whether I want to give "an application" access the default key chain without telling me which one. How could you decide whether an application should be allowed to access your passwords when you don't even know which one? This is not only insecure, it makes no sense at all.
Yeah, well, enough whining for today ... it's not that bad, is it ;)
New languages. New frameworks. New IDEs. New magic procedures...
Some of it is good, surely. Who programs without classes these days? But every time I see someone come up with a magic new net language, framework, etc., I sort of cringe. I mean, do we really need another one? Do we need all the ones we have (I'm lookin' at you, Ruby...).
The elephant in the room here that Microsoft, et. al. seems happy to ignore is that it takes time to learn AND recode this stuff. Time is money. If you're a teen or a student, you have time to mess with the next Ruby, or Dart, or GO, or BrainFuck or...
As a kid, you have no money invested, and plenty of time. There's no risk.
Fast forward 25 years. You still code for a living. You have a house, a wife, kid(s), car(s). You and your spouse are paying for all of this. Suddenly, genius boy at Microsoft invents Powershell! and convinces a few PHBs to roll it out. Suddenly, all your clients want Powershell! Quite frankly, you haven't got the time or interest in learning Powershell!. You wanted .net features added to VBScript and/or Jscript. You wanted backwards compatibility with existing VBscript and Jscript code. You wanted something that added value, not something that subtracted value by forcing you to go back to the drawing board and recode perfectly functional tools to satisfy a corporate IT security requirement from the corporate PHB that says, "Use Powershell!" for which you may, or not be paid, depending on how well your contract was written.
Disclaimer: I like Powershell, but it was the wrong decision.
The problem, quite simply, is this: Change!=Improvement. Change!=Better. Sometimes you get lucky. At other times, not so much.
Please do not read this sig. Thank you.
Ah, the trending tech phenomenon. Here's the harsh truth. Not only are most of the new tools just rehash of existing implementations coming to you at the cost of days learning and months of perfecting new languages, APIs and paradigms, but depending on your industry you may have an uphill battle convincing those in power that it's not worth the effort. Developers are tribe followers. We gravitate to passion and other developers who rise up with (in reality) mundane solutions that have been nicely packaged with pretty websites and a GitHub endpoint (all of this done to champion and advance the career of the originator in most cases who dreams of one day taking the podium at his own OSCON session) We need a cause.get behind and perhaps most importantly we need to feel as if the tools and patterns we use are always moving us forward so that we can feel of value and sell our value to the Fortune 500 companies and start ups that can afford the latest trending tech. We need to be able to convince people what we offer is giving them some strategic advantage. Almost always it is not. In most cases it adds more risk and cost to projects.But this isn't going away. If anything it's getting worse. As developers, sure we all genuinely want new tools to enable us to do the job faster but qualifying the good from the bad can be difficult and can honestly make you begin to hate doing this sort of work professionally in teams.
Yep, I live in the stone ages, but at least I know every corner of my systems.
What this world is coming to - is for you and me to decide.
I don't really understand what you're trying to say here. I don't know COBOL. Are you saying that if you gave me an assignment to parse a data stream in COBOL, and I couldn't do it in COBOL because I don't know COBOL, but I could both demonstrate a solution in another language and learn COBOL at a later date, I would still FAIL?
The trend I've noticed is that innovation has almost stopped, and has been replaced by change for the sake of change. Instead of innovating, people seem to be breaking things just to release new versions. Did Firefox really need to move View/Source? Did the atrocities of Gnome 3, Firefox 29, Windows 8, etc really need to happen? Was anything improved? Firefox breaks so badly that people write extensions to put it back the way it was - isn't that a clue that churn is getting too much?
The last few years have been filled with churn, but with no real progress. The number of programming languages is getting silly. (And they're starting to die as soon as they're announced, which is good. Seen any articles on Dart lately?) The way frameworks and libraries break themselves with each release is silly. The churn among frameworks is also getting to be ridiculous. How many MVC frameworks does Java really need? Ant is awesome, it works and can do everything, but there is a maniacal drive to throw it out and replace it. The much lesser Maven is taking over, and Google want to destroy the Android build process by inventing some lesser tool.
The point is that as an industry, we're reinventing the wheel every few years. That means endlessly trying to keep up with learning the same thing over and over again. Doing that is a silly waste of time, especially since there is a "shortage" of skilled workers. If there is a "shortage" the expedient thing to do is get back to industry standards so skills are portable. Why does every company have its own silo of technologies?
And as an industry, there is a "skills shortage" because if you don't know the MVC flavor of the month or whatever, you don't have the skills to do the job, even though picking up the skills is trivial because it's all the same stuff in a slightly different form. All anyone looks at is buzzwords on a resume, though, and we have to get beyond that to seeing what skills people have in software design, construction, and implementation.
All I'm saying is that no one can think of anything new to do, so they just churn out change for the sake of change just to have new releases. When it comes to tools and languages, the industry needs to get back to standards so that skills are portable.
Look ma! It's the latest entry in the Ask Slashdot bi-monthly series "What's the best way of getting back to coding"!
A good rule of thumb is that you must understand your program at least one layer of abstraction past the user layer to be truly competent with it.
That's frameworks, libraries, languages, whatever.
This knowledge is often the difference between the experts and the experienced novices, and I think we all innately know this once we've experienced it. Java provides a nice example, because they build that requirement into their certification program and learn about obscured concepts like memory utilization and object creation, but examples exist elsewhere. That 'Aha!' moment when you read Effective C++, or when you grok EF, or understand why Backbone.js does the things it does in the way it does them. I've even seen it on graphic designers who were forced to write raw HTML and CSS, rather than Dreamweaver or Muse.
This isn't even a program-from-bare-metal argument, it's just simply a matter of understanding the underpinnings in order to write decent code, instead of just adequate code.
There hasn't been anything new in CS since the 80s.
No really.
Nothiing.
AJAX was new. Used to be the terminal and back-end would only exchange data when you hit the xmit key, and of course the web re-invented this pattern adding nothing new, but then it actually went a step beyond. Of course, it's mostly abused in horrible ways to punish the user for the crime of being a customer, but then, what tool isn't?
Other than that, yup, mostly re-inventing of the wheel by people young enough not to be there for the last trip round.
Socialism: a lie told by totalitarians and believed by fools.
It seems really, really tough to get anyone finance-minded in the *business* of making software to understand that it's worthwhile to do exploratory development of tools and techniques to be much more productive later on.
Perhaps, but any such exploration and the resulting tools have to beat the baseline of a decent text editor, a decent version control system, a decent scripting language, and starting to write code within a minute of deciding the project is ready to begin.
For a long-running project with many developers and other contributors performing repetitive or error-prone tasks, maybe it will be worth investigating, selecting and adopting some external tools to automate some of that work, at some stage in the project when you know where the pain points are. But if your development team aren't newbies, they will be perfectly capable of building their code manually at first, they will surely already know their universal Big Three tools very well, and importantly, they will just code up any basic automation on the fly as the project grows and the needs become apparent.
IME, that turns out to be a surprisingly tough standard to beat. I've seen many, many projects get bogged down in their own infrastructure because they felt they should use some type of tool and forced themselves to do it, not because they necessarily needed that tool or found it useful in practice. Of course good tools can be useful, and of course sometimes it is better to bring in help from outside the project rather than being too NIH about everything, but it's important to stay focussed on the goal and not to forget that tools are only means to an end.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
That's all you need. (OK, implicit with c is the c compiler, pre-processor, assembler, linker, disassembler and strace). The old timers knew what they were doing.
Stick Men
Are you kidding? Efficient design peaked somewhere in 2000. Today, they're too simplistic, too spartan, and waste too much real estate, and then try to cover it up by sticking search boxes all over everything. The gap is only apparent because methods to complex processes have since been dumbed down for the benefit of illiterate users at the expense of making it as quick as possible for users who do know what they're doing to get at what is needed. This has made them harder to use for all but the simplest tasks.
I reached that point in the 90's.
Now I write all my code in a meta language that compiles down into COBOL, C, C++, C#, Erlang, FORTH, Fortran, Google's Go, Haskel, Java, Javascript, Perl, PHP, Python, Ruby, Rust, and more.
It takes about two weeks for me to learn a new language and write the "runtime" for my meta compiler. Then I can deploy all of my existing solutions on the new platform faster than the other guys can get "Hello DB Connection" out the door.
Fuck all the shitty languages and "new" platforms. Now that you've actually grown up and stopped being a fucking fanboy, go write your own meta compiler. I'll open source mine when I retire, it's what gives me the edge over all the noobs still wasting time reimplementing their wheels.
Not the same guy but I think we are on the right wavelength.
Here. Now go parse that stream using Cobol.
I dont care if you have ever heard of Cobol or not. I have never used it myself, and I havent been a working programmer in decades. But if I needed a parser written in Cobol I expect I could search for the docs first thing in the morning, find a syntax reference, and have a working if rough parser done before lunch. If this sort of work was needed by me on a regular basis I expect I would become very familiar with Cobol and a week later I would re-implement that parser in less than an hour and do a much better job.
All a computer can do is math, or if you prefer to think of it as symbolic logic, fine. But it's still all the same stuff. Any high level language you use, no matter how strange the syntax, no matter how unfamiliar the vocabulary, is still the exact same thing at core. Logic. Arithmetic. Algorithms.
A particular language may be a pleasure to work with, or it may be a pain but end of the day if you understand logic you should be able to translate your logic into any language for which you can find useful reference documentation.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
How much time do you waste with boilerplate crap like this because of nearly clumsy array-handling ideas that date back to the Great Flood?
How bloated is code because of the vacuousness of most common languages that
require
several lines
to do
the simplest
things?
With Erlang. You will learn something that is worthwhile and will last (it's been around for 30 years).
http://learnyousomeerlang.com/content
Offtopic a bit maybe, but the big problem of the larger "word processors" is that they try to supply half of a full desktop publishing system as well and it's not the useful half. You can spam pictures all over a page but can't place them precisely - you have to fuck about with other settings and hope they wobble into place.
IMHO it's the feature creep where the word processors approach DTP without getting there that gives that 90% that is marginally useful.
Similarly with IDE's that try to approach LabView but never get there - mainly because somebody points out that a LabView GUI is almost limited to a write-only approach for small and well organised bits of code and an unreadable spaghetti explosion beyond a certain size and complexity.
Q:How do tool smiths earn a reputation? Q:How do consultants retire from coding? The answer my friends is obvious, build more tools which are also more complicated and require constant throwing away of previous tools and work. Git is fine and interesting but has not solved the most important problem which is merging. And neither has the VSS, SVN, or VCS or anything else I am aware of. I haven't used a build tool yet that doesn't solve the dependency inconsistencies or merge issues that crop up. Code review tools are nice to have but only address the impact of changes in a very narrow area, usually only in the area where someone is looking which is often just a few lines of code.
Test automation is OK, but amounts to nothing more that regression testing. I have seen very few negative tests even though pumping noise into a program is easy to do.
I get this uneasy feeling now and then that we are focused on shiny things ("Oh look! it uses [funny animal | cartoon character ] as a mascot!"] and not looking at the fundamental, and sometimes hard, problems which if solved, or at least tamed a little, would really help.
putting the 'B' in LGBTQ+
It's right on!
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
For me my fast typing came from taking typing in high school 35 years ago. Hell, I don't know if schools even teach typing anymore.
15 years I coded with Qt professionally and came to love and adore it's quality and simplicity. I even wrote and operating system which was a microkernel and everything else was based on Qt Core.
I wanted to make a simple project the other day and Qt failed me. It seems that code goes in without unit tests these days and shipments are made without any quality control.
I used Qt because I'm not the typical loser Linux developer who wants to spend 50% of their time just fixing their tools or reporting bugs to package maintainers.
I was with him until he said use Subversion if it does what you need. I can't agree with that. Cheap forking is so superior that you have to learn it at some point.
Stop complaining about tools. It is an excuse for not writing code. A tool is only as good as the builder using the tool.
Here in Austin I see a lot of fads and tools. When you dare to suggest that it's really all about keeping it simple, or doing more with fewer lines of code, they look at you like you're crazy. They manage to cough out a program that passes unit tests after God knows how long and call themselves programmers.
why are you so sure everyone codes like you do?
Does your "Better idea" allow me to loop backwards/forwards arbitrarily while even allowing side-effects of the evaluation with multiple inputs/outputs/stepping/etc?
Seriously how is that worse than something crippled that can't do everything imaginable?
In a word its all about 'marketing'. The sales shivs cant sell you a new copy if they haven't got some new gizmo to flog. In my experience new code / versions often get as much worse as they get better, and so often a complete rewrite leaves you with a vastly inferior product. (That's how they created Windows Vista and Windows 8...) I wish the old saying nothing ever changes were true - it does change, it gets worse.. :D
Talking about excessive complexity. My loathing for modern dev tools and OS hit a head when the cutting edge app that I was creating - (that needed a custom memory manager) turned out to be impossible to create because I just could not get enough power over the OS. The next iteration switched to looking at Linux, better but still no joy. Then I looked at crafting a custom OS, this naturally was a nightmare, but then I hit the basic wall that there's no public documentation for a lot of the hardware and that everything needs to be done through custom device drivers - which require a standard OS. The next level was to look at embedded systems - these are much better and offer real control, but nowhere near enough processing power. The final solution was Verilog and FPGA, not so bad as there were always sub-units in this app that really needed custom hardware anyway. The punch line though is that it sets a timeline for completion that could be creeping up to ten years, a lot more costs, and...
Below the speed of light Special Relativity is one of the most accurate theories in physics - above the speed of light..
Turbo Pascal 4.5 - 6: I too loved it, & considered it a sort of "cross" between VB & C++ (instead of curly braces, it had "begin" & "end" statements, & each line ended in ; like C/C++) & I skipped Pascal for Windows, since by 1995 the "VB Killer" Delphi 1.0 16-bit came out (runtimes weren't necessary like VB, & thus, faster performing code - amazingly so, which I'll lead into next (even the use of Inline Assembler via the asm directive which I loved for certain areas, like looping performance gains (often double++ in fact), ala my post here to user "Perpenso" & the research backing that -> http://apple.slashdot.org/comm...
Delphi can do *almost* anything C++ can do & is OOP as well (except it lacks the multiple inheritance ability, & opted instead for the more, imo @ least, practically useable SINGLE inheritance model, & can even do drivers (with toolkits)).
Better yet? Check this out (what I was leading to here from above, on performance):
Back in 1997, in a competing trade rag that was widely read "Visual Basic Programmer's Journal" Sept/Oct. issue, Delphi (though downplayed to only 1 LINE to *try* to "hide it" but the graphs told the tale/truth) swept the floor with both VB & even MSVC++!
Delphi beat the hell out of MSVC++ in 4 of 6 tests performed in "Visual Basic Programmer's Journal" issue October 1997 entitled 'Inside the VB 5 Compiler Engine'...
ESPECIALLY IN MATH & STRINGS WORK - Which EVERY program, does, & here by HUGE margins.
Delphi lost 1 test of 6 to VB5 (ActiveX Form Loads) which even beat them both here (MSVC++ & Delphi) because it's MASSIVELY optimized for that. 5 of 6 to Delphi here vs. VB (with its 'watered down' C++ compiler engine that doesn't optimize loops e.g. vs. the 'real deal', MSVC++ from Microsoft).
Delphi lost 2 tests of 6 to MSVC++ in Graphics Methods. By a PUNY margin, of like .020 of a second here, & in TextBox Form Loads by another PUNY margin of .057 seconds. 4 of 6 to Delphi here.
The others were purely & largely won by Borland Delphi. By FAR larger margins than those, like 3x that in Strings vs. MSVC++ (300% faster), & 2x that in Math vs. MSVC++ (200% faster).
Where it won, it did so by HUGE margins/orders of magnitude, in programs created for like purposes with all 3 languages & fully compiler optimized.
VERY IMPORTANT THING TO NOTE? This test??
Was done in a COMPETING LANGUAGE'S publication no less - oh, they tried to "downplay" it of course, mentioning only 1 line about it in a 4 page article, but the charts?
Couldn't fool 'em... 10 tests were these:
1.) String Processing Suite
2.) Math Suite
3.) DataBase Suite
4.) TextBox Form Load
5.) Graphics Methods (rotating bitmap)
6.) ActiveX Form loads
APK
P.S.=> It's the reason I stuck by it since version 1.0 (Delphi) & loved Turbo Pascal 4.5 - 7.0 Object Pascal in 16-bit, then Delphi for Win16 -> Win32 -> Win64, & wrote this latest creation of mine in it for BOTH 32 &/or 64-bit code (It gives users more speed, security, reliability, & even anonymity online, AND, even shores up DNS redirect security issues ala the Kaminsky flaw, which 99.999% of ISP DNS servers are NOT patched for a decade++ later even when a patch has been out that long - it also does all that, & more, MORE efficiently than the "so-called 'competition'" in clearly INFERIOR browser addons by far, doing more from a single output file result than any single one there is, bar none -> http://start64.com/index.php?o...
... apkcid=47479729
Delphi can do *almost* anything C++ can do
Check on it yourself, ala -> http://en.wikipedia.org/wiki/A...
APK
P.S. => Did a LOT of VB to database work circa 1994-2006, however, I also did a LOT in Delphi (Object Pascal 7.x engines in 16/32/64-bit currently on the latter) in that timeframe professionally as well (with some C++ work in the mix too) -> http://developers.slashdot.org...
... apk
Compared with tools we had 10 years ago or more, UIs have indeed improved significantly.
I don't know what crappy tools you've been using, bub, but the Visual Studio UI is roughly the same as it was 10 years ago (and no complaints).
: )
Uh, Linux geek since 1999.