User: Password:
|
|
Subscribe / Log in / New account

Reitter: Answering the question: "How do I develop an app for GNOME?"

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 5, 2013 23:06 UTC (Tue) by zlynx (subscriber, #2285)
Parent article: Reitter: Answering the question: "How do I develop an app for GNOME?"

I surely hope the Javascript programmers are better than the Python programmers. I doubt it.

The problem is, dynamic languages make lazy programmers. They don't know or care what values a function might return. They only care about what it returns on success.

You might think that a Python library would return with an exception if it hit an error. How wrong. No, Python libraries return whatever the programmer felt like that day. If it returns a string in normal operation it might return an empty string on failure. Or False. Or None. Or a tuple of error code and description string. Or a custom Error object of some sort. Sometimes an exception. Pretty much at random, and the interpreter won't help you with a warning of any sort until an error actually happens.

This leads to the really annoying Python programs I keep running into on the Linux desktop where they work fine most of the time, but if you try to open a file on a network share and it returns some unexpected error the entire program exits with a stack trace.

Or the lovely errors and crashes the Fedora installer likes to return because it got an unexpected return value from probing LVM or RAID settings.

The VERY BEST THING for these programmers is to lock them into a C, C++ or Java straight-jacket and throw away the key. Hide the dynamic languages somewhere they can't find them. They might be allowed to use Go or Scala if they ask nicely.

Javascript is a horrible idea.


(Log in to post comments)

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 5, 2013 23:59 UTC (Tue) by FranTaylor (guest, #80190) [Link]

"dynamic languages make lazy programmers"

They also make programs that are easier to maintain by other developers because they are not overburdened with type information that is either redundant or irrelevant.

Have you ever worked in QA? Do you know where bugs come from? Many many bugs come from statically typed languages when square pegs are pushed into round holes by implied casts. You can say "experienced developers should not fall for this" but the simple fact is that even the most experienced developers create far more bugs per LOC in static languages than they do in dynamic ones.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 0:50 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> They also make programs that are easier to maintain by other developers because they are not overburdened with type information that is either redundant or irrelevant.
Modern languages have type inference.

> Have you ever worked in QA? Do you know where bugs come from? Many many bugs come from statically typed languages when square pegs are pushed into round holes by implied casts.
The issue here isn't static typing but what you call "implied casts". And in fact, sensible languages don't have those except in cases where they're guaranteed to work (i. e. subtype to supertype conversions, integer widening).

> You can say "experienced developers should not fall for this" but the simple fact is that even the most experienced developers create far more bugs per LOC in static languages than they do in dynamic ones.
Bollocks.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 3:21 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> They also make programs that are easier to maintain by other developers because they are not overburdened with type information that is either redundant or irrelevant.

I understand "redundant" but irrelevant? Care to give an example?

> Do you know where bugs come from? Many many bugs come from statically typed languages when square pegs are pushed into round holes by implied casts.

IME, at least I can get a static-typed language's compiler to warn me about cases. Python, PHP, JS, etc. just chug along merrily without a peep.

> You can say "experienced developers should not fall for this" but the simple fact is that even the most experienced developers create far more bugs per LOC in static languages than they do in dynamic ones.

I believe the research that I heard about[1] last found that bugs per LOC is about the same in every language[2]. It's just that "scripting" languages (which tend to be dynamic-typed) typically need fewer lines to do what they need.

[1]I'll try to find it.
[2]I'd be interested to see if PHP and bash are outliers in this and if so, by how much.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 18:11 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> I'll try to find it.

It seems that this[1] StackOverflow post is a place to launch from.

[1]http://stackoverflow.com/questions/2898571/basis-for-clai...

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 21:17 UTC (Wed) by khim (subscriber, #9252) [Link]

They also make programs that are easier to maintain by other developers because they are not overburdened with type information that is either redundant or irrelevant.

Care to offer an example of a sizable program which is 10+ years old, not maintained by the people who've written it 10 years ago and which is written in a dynamic language?

There are many such programs in C and enough in Java, but I'm yet to see anything like this in a dynamic language. When people who designed stuff are moving from project programs in dynamic languages quickly turn to unmaintainable mess and are usually rewritten. This is direct opposite to "easier to maintain" in my book. Programs in statically typed languages are kept around for decades (Cobol jokes aside there are a lot of programs in statically typed languages which are still in use).

Have you ever worked in QA? Do you know where bugs come from? Many many bugs come from statically typed languages when square pegs are pushed into round holes by implied casts.

Have you ever worked with security teams? Do you know where bugs unnoticed by QA but actively exploited in the wild come from? Many many bugs come from dynamically typed languages (primarily JavaScript and PHP, of course) which "do the right thing" in hothouse QA testing but then break apart in the wild.

If you want to create program which will frustrate QA but which which will work reliable once released - use statically typed languages, if you want to create program which easily passes QA but then guarantees lifelong job insurance because someone needs to plug security holes again and again - use dynamic languages.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 1:17 UTC (Thu) by dirtyepic (subscriber, #30178) [Link]

>Care to offer an example of a sizable program which is 10+ years old, not maintained by the people who've written it 10 years ago and which is written in a dynamic language?

Portage.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 6:10 UTC (Thu) by khim (subscriber, #9252) [Link]

Portage is great example of the phenomenon described above: it had few serious instances of typical dynamic languages crises of "we don't understand what goes on here and don't know how to fix that" variety, large pieces of it were rewritten in not-really-backward-compatible-manner because noone knew what goes in some pieces of it... and it's still a PITA for a Gentoo developers because of all these problems.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 5:05 UTC (Thu) by bronson (subscriber, #4806) [Link]

sysvinit :)

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 9:23 UTC (Wed) by epa (subscriber, #39769) [Link]

I feel your pain and of course I would like to set up some Inquisition where programmers are tortured until they carefully handle and document every error case and return condition in every line of their program. However, I think you are being unfair in attributing this to dynamic languages. There is a huge amount of C code which doesn't handle error cases well, resulting in your application going kaboom when using network shares and so on. C++ and Java give you a richer toolset for handling error conditions but they still can't force programmers to use it sanely; and again, there is plenty of code in those languages with terrible error handling.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 17:22 UTC (Wed) by HelloWorld (guest, #56129) [Link]

Well, actually it's pretty hard to screw up exception handling in Java due to checked exceptions. You have to write additional code to ignore an error, there's not much more a language can do.

(and no, you shouldn't take this to mean that I somehow endorse Java. I don't, it plain sucks as a language.)

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 21:45 UTC (Wed) by zlynx (subscriber, #2285) [Link]

And for C/C++ there is usually a compiler option to warn/error about ignored function return values. This is incredibly useful and should be required.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 21:58 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

Unfortunately, C code that meticulously collects the return value of everything that can fail essentially-harmlessly is a real pain in the neck to read, because it's salted either with cast-to-void or with piles of pointless error-checking logic. (I hate reading C code where some coding-standards martinet has insisted that all printf() calls must be cast to void.)

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 8, 2013 14:51 UTC (Fri) by jwakely (guest, #60262) [Link]

> And for C/C++ there is usually a compiler option to warn/error about ignored function return values.

What's GCC's option for that?

You can use __attribute__((warn_unused_result)) but putting that on every function returning non-void is hardly practical, let alone portable.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 12, 2013 19:51 UTC (Tue) by mgedmin (subscriber, #34497) [Link]

-Wno-unused-result exists, according to the gcc(1) manual page.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 12, 2013 20:21 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

The -Wno-unused-result option does exactly the opposite of what is wanted: it turns off the warning which would otherwise be issued for functions which have been tagged with __attribute__((warn_unused_result)). You still have to tag specific functions whose results should not be ignored. There does not appear to be an option to enable the warning for all non-void functions by default.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 12, 2013 21:03 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

Enabling the warning for all non-void functions by default leads to code being liberally salted with futile error-checking and/or casts-to-void.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 12, 2013 22:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Futile?

Nope. Apart from maybe printf() - most of the error checking is necessary for secure code.

It just shows that exception handling is really much better than return codes when you want something that's reliable _and_ easy to read.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 12, 2013 21:04 UTC (Tue) by zlynx (subscriber, #2285) [Link]

You are right that there is no global option in GCC. I was thinking of the per-function attribute.

Warnings about unused results are also common in code analysers like Splint and others.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 1:44 UTC (Thu) by ThinkRob (subscriber, #64513) [Link]

> Well, actually it's pretty hard to screw up exception handling in Java due to checked exceptions. You have to write additional code to ignore an error, there's not much more a language can do.

Oh no, there are ways.

Like someone deciding to make a base exception class that extends RuntimeException thus does not need explicit 'try'/'catch' handling or 'throws' declarations.

Sadly, this is not purely hypothetical. I've worked on codebases where this was the case; damn near everything was a runtime exception. It was very explodey.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 6:15 UTC (Thu) by khim (subscriber, #9252) [Link]

It was still relatively safe. Explodey programs are bad, but programs which are silently doing the wrong thing are worse. And languages like Javacript or PHP tend to produce exactly such a thing.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 8:23 UTC (Thu) by ekj (guest, #1524) [Link]

PHP is indeed fucked up, but most of that is just a case of "we made dumb choices once upon a time, and now we can't fix it because then we'd not be backwards compatible".

Nobody really thinks it's a good idea, for example that "0.0" == 0 is true but if(0) and if("0.0") has opposite effects. (i.e. despite the fact that "0.0" is claimed to be equal to 0, nevertheless one of these is considered "true" in a boolean context, while the other is false.

if ( $a == $b && $a && !$b) is potentially true in PHP, and that's just *one* example of the mistakes made while designing this language.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 11:58 UTC (Thu) by khim (subscriber, #9252) [Link]

if ( $a == $b && $a && !$b) is potentially true in PHP, and that's just *one* example of the mistakes made while designing this language.

Well, it look like we are in violent agreement, then. JavaScript's analogue:

> a = "0"
  "0"
> b = 0
  0
> a == b && a && !b
  true

JavaScript is fucked up for the very same reason PHP is fucked up: they try to "silently fix novice's errors" - and in real programs this tends to lead to security holes sooner or later (usually sooner). Neither PHP not JavaScript should be used directly "as is". Never. Solution for PHP: don't. Just forget about PHP and use some other languages if posible. There are many of them: Java, Python, even C or Perl are better then PHP. Just don't. Solution for JavaScript: use some higher-level language which is compiled to JavaScript. There are quite a few contenders at this time: CoffeeScript, TypeScript, even subset of Java (if you use GWT).

To add JavaScript to your desktop environment as a primary development tool? Gosh, what are they thinking? Do they hate developers this much?

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 13:38 UTC (Thu) by ekj (guest, #1524) [Link]

Yeah. We appear to agree. I'm just tired of those people who think that these problems can only be solved (or atleast improved upon) by having a statically typed language.

Python is, IMHO proof that it's possible to solve many of these problems and have a cleaner, safer language while remaining dynamically typed.

In Python 0 == "0" is False (indeed 0 == any_string_whatsoever is False)

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 16:25 UTC (Thu) by khim (subscriber, #9252) [Link]

Yeah. We appear to agree. I'm just tired of those people who think that these problems can only be solved (or atleast improved upon) by having a statically typed language.

These programs can not be ever be solved (you can write Fortran in any language) but they can be reduced. Statically typed languages are on one side of the spectrum (and there there are different shades of gray, too): a lot of problems are detected when you try to compile program. Dynamically typed languages are the next best thing: problems are detected in runtime and end user observes see "[x is out of range]" instead of "there are no page to edit" message, but the PHP is at the other end of spectrum: user does not see anything wrong while it's data is slowly corrupted beyond repair. JavaScript is close behind.

Python is, IMHO proof that it's possible to solve many of these problems and have a cleaner, safer language while remaining dynamically typed.

Sure. But it still does not make it usable for an industrial projects. Which are defined not by size but by staff turnover: it's not uncommon to see project handled by 4 or 5 generations of programmers in the course of 10 years in a commercial environment - and each generation start with the code but without help from the previous generation. Dynamically typed languages almost wholly unsuitable for such a development, statically typed languages fare much better.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 12:11 UTC (Thu) by epa (subscriber, #39769) [Link]

Well, actually it's pretty hard to screw up exception handling in Java due to checked exceptions.
Including out of memory conditions?

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 11:11 UTC (Wed) by pboddie (guest, #50784) [Link]

Kids these days, huh?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds