|
My experience there was different, as I went from C++ to Java for a bit. C# was like a breath of fresh air, and LINQ sealed it for me. These things have spoiled me; going back and working in C++ for anything past low-level protocol work feels like a drag.
So...yeah. About 7 out of 10 (LINQ solidified that for me).
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I used to use C++ MFC for everything but when it became merged with .Net I moved on to C#. I still feel a little nostalgic but I seem to have forgotten almost everything I learned. Oh well...
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
John Simmons / outlaw programmer wrote: I would rather deal with someone else's bug-ridden code rather than my OWN bug-ridden code?
I guess one of the advantages of a good library is that by the time you get your sticky little fingers on it, thousands of other hopefuls have already suffered from the most obvious bugs and the worst of them have been sawn-off, sanded down, patched with filler, or occasionally even fixed!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I prefer the work-around, band-aid and bubblegum approach, it's what I'm used to. 
It was broke, so I fixed it.
|
|
|
|
|
Hey lets not leave out spit & bailing wire! 
|
|
|
|
|
glennPattonInThePUB wrote: spit & bailing wire
That's real old school.
It was broke, so I fixed it.
|
|
|
|
|
new is not always better, Win 8 for example...
|
|
|
|
|
Vines and sticks is REAL old school.
|
|
|
|
|
glennPattonInThePUB wrote: bailing wire
When I grew up, we only used bailing twine, not wire...
Then, working in a pulp and paper facility, the pulp bails were held together with wire, so I then understood how it was used.
Still prefer the twine, though. We'd gather it, tie them end-to-end, get three lengths and braid them to make rope.
|
|
|
|
|
|
When I was growing up, it was No. 8 fencing wire. (NZ has a lot of wire fences)
It's just on the edge of being bendable by hand and then use a tool for final tightening.
Since it was always on hand, you'd use it to make makeshift repairs from saddles to tractors, as gate latches, snip and sharpen to use as nails, large loop as a tow rope, loop and hang slaughtered sheep on a tree, staple a snapped fanbelt back together...and that's just the things off the top of my head.
|
|
|
|
|
And it's permanent-repair companion: duct tape.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
:shakeshead: Duct Tape, I tend to use the term Gaffer Tape...
|
|
|
|
|
Nah. No way would the films have been watchable if Bruce Willis was crawling round in a Gaffer for most of the movie ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Too bad this does not apply for languages, javascript would have profited from it.
|
|
|
|
|
Isn't that the theory also behind open source?
|
|
|
|
|
Yes - but open source software tends to get hacked about to get a specific feature added, with no overall "target" in mind. Libraries tend to be a bit more focussed and intended to "do X" rather than "do most of X and some of Y because I could use that".
Having said that, I do use OS apps: Freemake Video Converter, Handbrake, and Libre Office for example.
But Gimp I don't like - I pay money to Corel instead ( :sob: ).
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
John Simmons / outlaw programmer wrote: Or that I would rather deal with someone else's bug-ridden code rather than my OWN bug-ridden code?
Exactly my sentiment. 
John Simmons / outlaw programmer wrote: Maybe it's time to retire...
That too. 
John Simmons / outlaw programmer wrote: People are really funny.
If by "funny" you mean, for example, some newbie waltzing in and replacing 10 lines of working code that took 10 minutes to write with a huge general parser library that he can't get working after five days, and because he has some Haskell experience he convinces the CTO that everything should now be written in F#, then yeah, but somehow I fail to be amused. 
Marc
|
|
|
|
|
Marc Clifton wrote: If by "funny" you mean, for example, some newbie waltzing in and replacing 10 lines of working code that took 10 minutes to write with a huge general parser library that he can't get working after five days, and because he has some Haskell experience he convinces the CTO that everything should now be written in F#, then yeah, but somehow I fail to be amused.
In that case, the person isn't funny as much as he is a target of opportunity.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Marc Clifton wrote: somehow I fail to be amused
I guess you're not funny enough 
Speaking of which, I better convince Chris and his team to re-write CP in Haskell, because that will certainly enhance my user experience
|
|
|
|
|
It's no different when you retire, people are just as stupid.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
John Simmons / outlaw programmer wrote: Maybe it's time to retire...
Man, if I had buck for every time I thought that... well, I'd be able to retire
-NP
Never underestimate the creativity of the end-user
|
|
|
|
|
People like to show off. For me a library is non-intrusive well documented collection of code that is designed to solve a single generalization of a common problem. Unfortunately, a lot of libraries are just out of idea collection of random advanced code collected from random application that solves author's issues, namely "your application should look like mine application, otherwise you have the wrong idea".
|
|
|
|
|
Your question is one of the first signs of realistic thinking in the software profession I have seen in quite a long time.
You are quite correct to ask how this or that framework or paradigm will satisfy the requirements you have for a particular project.
The majority of the freely available, open source frameworks, no matter the targeted platform are the results of agendas seen by the developers as universal. This may be from experiences they have had while working on other projects, books they may have read, lectures they may have attended, promotions by colleagues, or some combination of the aforementioned.
This is not to say that such frameworks are bad; just often limited in what they can provide.
As a much older software engineer I see the current rush for new tools, paradigms, and frameworks as a sense of floundering within the profession as even vendors in the Microsoft Community try to promote the latest "silver bullet" to everyone. Interestingly enough, the Java Community does not seem to suffer these same issues to the same extent.
If you review the "jaxEnter" community site you will note that much of what is presented are refinements to existing and older technologies that work quite well for their needs.
One area where Java developers have excelled at is with the development of the web with the MVC paradigm. This is because this was always the way that Java web applications were developed.
However, you also have to understand that the Java Community also grew out of academia and scientific areas where Microsoft was more of a "developer's" vendor from the start.
Currently, our side of the fence is littered with tools, frameworks, and paradigms all claiming to be the best and right way to do something. If that is the case how did we accomplish anything back in the 1990s or the early 2000s when such offerings were not really available? What we did was simply use sound concepts to built applications with the basic tools we had. And we did quite well at it.
Your question brings up another question then. Would it may be better to return to those basic techniques and skip all the hype? You may find coding much easier, more enjoyable, and less constrained by the limitations of the current psychological pressures to develop in certain ways.
I never moved on with the younger crowd when it came to technologies. I still program the way I have always done and with few defects in my work, practically none of which ever make it into production releases.
The next time you have a project, ask yourself as to how best you can provide a good result without all the gobbledygook that current environments encourage. Instead of "adding" try "subtracting". You will probably find that you can create a great application just as easily by concentrating on building it than trying to figure out what type of technologies you are being encouraged to put into it...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
