Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[gnome42]

Python is so awesomely easy x3

My major complaint about Python.

Proper English grammar is what should be enforced...

Anyway, we don't really do "my language is better or that one sucks because" stuff in this topic as that doesn't get anyone anywhere.

Spoiler (click to show/hide)

Unless it's Java, of course.

Not that C is better.  There are more subtle and outright ways to hang yourself in C than about any other language.

Most other languages will complain about the kind of abuse that can go on in C, that may or may not be intentional.   The unintentional abuses will get some of the most interesting results you have ever had to debug out side outright compiler fun.

This was a case of having to debug one of my 11 year old daughters programs in Python, so it is a learned hatred.
I'm sorry, either it complains about the formatting while refusing to work, or it does not rely on it. 
Pick one.

Yes, I am a hard core, old school C coder. 
I also recognize that  the result and needs dictate the choice of languages.
Java, Python, Fortran, Cobol, Pascal, C, all of them have a place and very appropriate use.

Unfortunately, very few people are coming into the job world with this kind of training.
They think that what they know is the end all, be all of how to implement something.

Look at the impacts of what you are trying to achieve.  Weigh the benefits against the drawbacks if each choice.
Use what is most suited to the goal.

For many areas, Python is a very apt choice.  ( I may loath some of the language design choices, but I will admit to its aptness for certain applications )

I do real-time transaction processing.
For my use, C is the best choice.
The absolute certainty over memory allocation, some of he most mature optimizers in existence, most abuse possible of data, makes it the obvious choice.

Does this make C the best choice for other uses?
Oh, hell no.

Being familiar with many languages, the benefits, and draw backs of each is a very important skill long term.


gnome

[MorleyDev]

It's worth noting that some languages, like Cobol or Fortran, have been replaced by languages that can accomplish exact the same thing but are better. So whilst they were appropriate, their only remaining "appropriate use" is historical or tied to certain old machines.

So the real discussion in terms of worst language should be what language would we suspect to be close to or ready for the chopping block, confinement to history and banking systems? Are there any 'current' languages that have had everything it was once good at superseded by other languages that do the same but better?

[gnome42]

It's worth noting that some languages, like Cobol or Fortran, have been replaced by languages that can accomplish exact the same thing but are better. So whilst they were appropriate, their only remaining "appropriate use" is tied to certain old machines.

So the real discussion in terms of worst language should be what language would we suspect to be close to or ready for the chopping block, confinement to history and banking systems? Are there any 'current' languages that have had everything it was once good at superseded by other languages that do the same but better?

It is not so much old machines, as it is upwards to 50 years of legacy code.  Backwards support is always a selling point for especially the Big Iron. IBM produces machines to this day that support native binaries from 40 years ago.  There is a reason for this.
Nobody wants to go and rewrite 50 million lines of code that works.  It is maybe not the best.  Or the most efficient any more given the changes in hardware, but good enough. 

Hmm.  An interesting question.  Possibly Pascal.  Then again it was designed as a teaching language.  It's purpose was to be a straight forward language to use to teach programming concepts.  Hence some of it's more frustrating B&D elements.  Which it did serve very well as.  Keep the language simple and straightforward, that way the students can concentrate on fundamental concepts.  However a draw back to this is that it kept getting used, instead of replaced by a language designed from the beginning to do work.

COBOL is possibly one that has outlived it's design goals.  Which was to be easy to access for non-programmers.   

Any of the Database languages are another option.  DBase, foxbase, etc.  They have been pretty much replaced by SQL servers, and libraries for about any language you like.


gnome

[ECrownofFire]

It's worth noting that some languages, like Cobol or Fortran, have been replaced by languages that can accomplish exact the same thing but are better. So whilst they were appropriate, their only remaining "appropriate use" is historical or tied to certain old machines.

So the real discussion in terms of worst language should be what language would we suspect to be close to or ready for the chopping block, confinement to history and banking systems? Are there any 'current' languages that have had everything it was once good at superseded by other languages that do the same but better?

COBOL is still living, though mostly in the undead sense.

I mean shit, there's a new standard set for publication this year.

[gnome42]

COBOL is still living, though mostly in the undead sense.

I mean shit, there's a new standard set for publication this year.

Undead is accurate.  Inertia. 
Plus too expensive too replace all of it with something else.
The three biggest users of COBOL code that predates almost everyone here are Insurance, Banks, and State Agencies.
Most likely the three most conservative sectors in existence.

It boils down to not having the man-power/budget to replace what works. 
Sure it could be rewritten in almost anything else, and most likely be more efficient, but the cost of the rewrite is not justified yet. 
Give it another 15 years.  Most of the old school COBOL folks will retire by then, and management will have come out of a more modern perspective.

We just have to hope as supplicants of these systems that they are re-written/designed by good code monkeys.


gnome

[gnome42]

And just to address a few things from earlier with a non programming example.

Say you have at you disposal the cars/trucks.

One is an little two seater fourbanger.  Great gas millage, no storage.
One is a large truck.  Crappy gas millage, but massive storage/hauling.
One is a tractor.

Now you have three things to do.

Drive to work ever day to an office 30 miles from your house.
Pick up 4 tons of retaining wall block to build a somthing in the yard.
re-gravel the drive way.

Now you could take the tractor to work, resurface the drive way with the big truck, and fetch the reataining wall block with the commuter.
But you would be an idiot for doing it this way. 

Owning this collection is a capital outlay that only some can afford.
The premise is the same for programming, only the cost of entry is much lower.
If you understand the concepts of programming, the specifics are minor.=
Learning a new language is cheaper that the effort spent using the wrong one for anything that is not a one off/toy project.
Never be afraid to learn a new language.  Just because it is what you know the best does not make it the best choice for the project.

Look at what you have to achieve.  Just because you were taught JAVA in school, does not make it the best choice for the project at hand.
Every language has it's draw backs.  Learn them.  Look at other languages.  Could Fortran 77 be your best way of doing this? 
Do it that way.

Hence the precept of tailor the language choice to the needs.
No language is the best for everything. ( and many are the wrong ones )
Proper design is far more important.
Work out the needs of the project, then chose the language that fits them.
What works the best?
Are there overarching factors, such as time lines and knowledge base?  Very much so.
But that should never stop a Code Monkey from standing up in a meeting and stating " Yes, we can do it in this way, but it has these ongoing performance costs/support costs.  I might be able to pull it off in X language for 1.5 the start up time/but half the ongoing support costs." 
If you are going into a career as a Code Monkey, never be afraid to learn another language.  Do not do it because it is the language of the week.  But because many languages have their areas of best suitabilty.  Learn to understand ( and possibly beat out of the client with a 2x4 ) the needs. 
This is the best lesson you can learn at a young age.  Clients lie.  They have a final vision that has little intersection with reality.  Learn to bore down to what they are trying to achieve.  What is their vision?  Not what do they think they should see.  But what are they trying to get to.  These tend to be vastly different.  Learning how to guide end users into this path is one of the hardest things to learn.  And it is never taught in college.
You learn it the hard way most of the time.  Trial by fire.  And everyone gets burned.

Innovation is one of the things that should be taught in college.  Very few do so.

Just trying to get the next generation of code monkeys to learn some of the hard lessons that took 25+ years of paid work to learn.

gnome
 

[Skyrunner]

Now I have to use Java again, this time to produce a prototype of a graph GUI to compare with the slow Python-pygtk one. D:

[Anvilfolk]

Skyrunner - graph as in directed graphs? If you're interested in putting a Java version of that to actual use, we could really use it in the Agora project PM me or write in the topic (see sig) if you're interested!

[gnome42]

Now I have to use Java again, this time to produce a prototype of a graph GUI to compare with the slow Python-pygtk one. D:

A simple graph?  web based? 
Heck produce it via Gnu-Plot.  Last time I looked there were options to produce a .jpg as output.  So relatively simple to include in HTML on the fly.  Even in other applications, is can be simpler to use what is out there than to code it from scratch. ( Yes, there are cases where this is required.  I deal with them every day.  Nothing like coding up a Binary-tree library from scratch.  I am also working on a b-tree lib when I am bored, we need one, and keep using less than optimal solutions since we do not have one ).

Remember, anything that is more than five years old most likely has mature library support.  The only reason to avoid using it is to avoid copyright issues.  They can get messy, and explaining GPL, MIT, or other such issues to lawyers has more in common with head-butting a brick wall than anything else.

gnome

[Skyrunner]

Interactive graph.

Using Gephi output to draw a graph I can interact with. I want to use pygtk but the Java Processor library was suggested as an alternative, so I'll make a Java version and compare them. The pygtk+cairo version is a bit slow when scrolling, and I can't figure out why. GUI widget frameworks are so hard to use.

[gnome42]

Interactive graph.

Using Gephi output to draw a graph I can interact with. I want to use pygtk but the Java Processor library was suggested as an alternative, so I'll make a Java version and compare them. The pygtk+cairo version is a bit slow when scrolling, and I can't figure out why. GUI widget frameworks are so hard to use.

Sorry, outside my area of expertise.
Just a guess though is how the support libs are implemented.
They are probably redrawing things every time the focus moves.  Great for short term drawing, crap for dynamic output.
 
Good GUI work is really very hard to implement.  It requires a certain mindset than only a small fraction of code monkeys understand.  ( I am shit at them.  I know bad implementations when i have to use them, but am worthless for designing good ones ) Even the folks that have to support them on a regular basis, only a select few should really be doing it. This is where Art intersects CS ( and we need more of these people every day)

It is a matter of thinking in twelve different ways all at once.  Not just how you would use the screen, but eveyone else.  And you are in the minority.  No matter what you do, and design into it, it will annoy someone.  A few of these folks you can look at with scorn.  The rest you look at yourself and wonder why you never thought of that, it is so much easier from a user standpoint.   UI is hard  I salute all my co-workers that do it daily. 


gnome

[gnome42]

Okay time to get up on the soap box.
I've 25+ years of being a code monkey for hire, and you junior lot need to know a few things before you get slapped in the face at 0300.

1)  you are always wrong.
  This could be due to entrenched beliefs.  You fight these cases when you can support you position.  You have to recognize when it makes sense to stand your ground against the entrenched higher ups due to very valid reasons, and when to listen too them based on their experience. This is the hardest thing you will learn in your career.  When to fight VS when to give in when it does not matter.  ( one of the hardest lessons to learn. )

2) if you look at what has gone before, you are smarter than you think.  90% of code is written by junior engineers.  Half of it by the people you are arguing with, that if they have any salvation, realize it is shit code.  I have gone back over code from 10 years ago and looked at it and said " what fucktard wrote this shit? Oooh it was me" Every one writes crap code early on.

3) Do not focus on a language.  You can pick any of them up in under a month if you try.  Will you be a GURU?  Nope.  but you will get by.  What is important is understanding how to do things.  You can achieve the exact same things in JAVA, C , Python, COBOL, Language Of The Week.  The effort may be different, but it can be done.What you learned in college is most likely the wrong choice.( I learned C over the summer one year in college due to Pascal being less than optimal for a new command line shell for a Prime computer )

4) basic flow structures.  Learn them. they are the same in any language, only the syntax varies.

5) The language of the week is never the correct choice.  Well it might be. Or it is the worst.  Learn how things work,  What are the costs of this every time it is executed?   Does it have massive memory leak?  Does it cost me a 3 second delay while it is started?
what works for a one-off does not work for a resident program expected to stay up for months/years at at time and the flip side holds true.  ( it may leak like an IH Scout on the driveway, but we are killing it after 1 second, so who cares? )

6)  Play.  write the absolute crap code to see what happens( and break the compiler ).  Improve it.  laugh at it.  If you get bored at work, re-write a standard lib from scratch.  Or maybe try to implement an ADA tokenizer in Befunge if you have a real S&M streak.  What you can learn from this exercise in self abuse would surprise you.

7) what works for 1000 samples never works for 1 million.    Your test data is crap.  Always and ever.  Be very aware of scaling.  Just because something works for your limited data set, does not mean it works for the real world usage.  If you are very lucky QA catches it before it goes live.  Otherwise you get to debug a live system on the fly.  Pissed off customers are never fun. Try to limit your screw ups to off hours.

7)  Never completely trust your instincts.  Always at the very least do basic testing of you changes.  The worst errors tend to be the most basic ones, and these can be caught with the most basic testing of functionality.  The hell a misplaced ';' can cause should never be over looked.  Or an un-initialized variable.  (" how in the hell did this go negative?  everything that leads into it is a +?  Ohh, shit, that variable is whatever crap is on the stack. I never set it to zero."  Worse is when it is a pointer and the stack randomly gets trashed.  Debug that...)
 
9) try to limit your fuck-ups to off-hours and never lie about them  Really.  No-body really cares unless you make a habit of it.  You have a missed bit of code?  Does it effect the customer ( and did you outright admit you screwed it up?  Any manager that does not accept this and go forward when it is the exception should not be there.   Everyone fucks up.  No exceptions.  The lucky among us have it caught by QA before it goes live.)  If you have a good customer, any reasonable screw up is not a big deal if you tell them what the issue is without whitewashing." I screwed this up.  This is how we fix this."  Never lie to them.  You will run into the customer that knows more than you think, and they will call you out on it.
And at 0300 a good relationship with the customer can never be underrated.  They have he final say so, and a hell of a lot of the decision making does come down to trust.  In some cases, who cares if we install it now or at 10 am?  Others?  Now.  Let us limit the damage to both of us.   And having a good relationship with the client goes a hell of a long way to getting stuff in sooner.

Okay I though of something else. 
10)Realize that both iterative and recursive searches are crap.  But understand the why of the crappiness.  Understand the trade offs made for each way of doing things.  ( if you have a very good Database backend this becomes a non-issue, but you should still understand the cost of each choice, since all of them suck for different reasons. )

 
TLDR:  Stop picking the language of the week,admit when you screw up, and never go on what you learned in college.


gnome

[Telgin]

7) what works for 1000 samples never works for 1 million.    Your test data is crap.  Always and ever.  Be very aware of scaling.  Just because something works for your limited data set, does not mean it works for the real world usage.  If you are very lucky QA catches it before it goes live.  Otherwise you get to debug a live system on the fly.  Pissed off customers are never fun. Try to limit your screw ups to off hours.

There's a lot of truth in that post overall, but I'm going to highlight this one as something that continuously bites me in the butt at work.  No matter how many times I test a piece of code with different inputs, or how large of a data set I try with, inevitably somebody comes along and tries an input I didn't expect or to use it for 100x the data size and I learn it doesn't scale up.

Case in point: in the past month our company deployed an upgrade to our property management system used by property managers at these student housing communities.  That upgrade included the ability to send text messages to students or other residents.  We tested the code repeatedly and it worked perfectly for up to about 50 people at a time.  Great, if it returns in <1 second for 50 people, it's perfectly fine, right?

Well.  The first thing someone does is try to upload a .csv file of 600 people.  That turns out to take several minutes to upload because we were doing a lot of unnecessary HTTP requests to our centralized API server, and people think it's hung up.  Commence hitting the submit button multiple times!  We had to fix it so that it disables the button (like it was supposed to do already) and had to optimize the code a lot to get it to work at acceptable speeds.

The next thing that happens is someone tries to upload a .xls file.  That won't work at all, and the code still expected a .csv file.  Cue thousands of people being uploaded with phone numbers like @#XDER)_@231.  Then people try uploading .csv files with the columns out of order, even though we provide an example .csv file.

Actually, I guess the moral of this story is we need some dedicated quality assurance people here.

[Skyrunner]

The People were QAing for you!

[gnome42]

The People were QAing for you!

And to step back on the soap box for a minute...
This is why a lot of supposed "production" software is crap.
Does some of this come back to the code monkeys?  Yep.
But we are not perfect.
we need an outside resource to take a second look at stuff. 
We hav pre-concieved notions of how stuff should work.
We need the 12 year olds to beat the snot out of the software and find the border cases.
To work in a way that we have not thought of, since we are to entrenched in how it should work.

QA are the best friend of a code monkey, even if you do spend large amounts of time teaching them the basics.