Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.ipad > #46126 > unrolled thread

Hello World

Back to article view | Back to comp.mobile.ipad

Contents

  Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-07 12:53 -0600
    Re: Hello World Inge Svensson <ingesvensson@bredband.net> - 2015-03-07 19:58 +0100
    Re: Hello World Doc O'Leary  <droleary@2usenet2014.subsume.com> - 2015-03-08 15:02 +0000
      Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-08 14:51 -0500
        Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-08 20:41 +0000
          Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-08 20:44 +0000
          Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-08 16:51 -0500
            Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-08 16:11 -0500
              Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-08 17:23 -0500
                Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-08 22:51 +0000
                  Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-08 22:52 +0000
                    Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-08 21:52 -0500
                      Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-09 12:09 +0000
                        Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-09 07:52 -0500
                          Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-09 13:31 +0000
                            Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-09 09:04 -0500
                              Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-09 11:10 -0500
                                Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-09 10:14 -0500
                                  Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-09 11:26 -0500
                                  Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-09 17:32 +0000
                                    Re: Hello World DMcCunney <dennis.mccunney@gmail.com> - 2015-03-09 14:57 -0400
                                      Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-09 15:07 -0500
                                        Re: Hello World Alan Meyer <ameyer2@yahoo.com> - 2015-03-09 16:19 -0400
                                          Re: Hello World Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-03-09 22:02 +0000
                                          Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-09 22:36 -0400
                                            Re: Hello World Tony Cito <tonycito@this.is.invalid> - 2015-03-10 13:23 +0000
                                              Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-10 19:50 -0400
                                        Re: Hello World DMcCunney <dennis.mccunney@gmail.com> - 2015-03-09 19:28 -0400
                                          Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-10 19:50 -0400
                                            Re: Hello World DMcCunney <dennis.mccunney@gmail.com> - 2015-03-10 20:58 -0400
                                          Re: Hello World Alan Meyer <ameyer2@yahoo.com> - 2015-03-10 22:31 -0400
                                      Re: Hello World Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-03-09 19:14 +0000
                                    Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-09 15:07 -0500
                                  Re: Hello World Alan Meyer <ameyer2@yahoo.com> - 2015-03-09 13:56 -0400
                                    Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-09 15:15 -0500
                                      Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-09 16:19 -0500
                                        Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-09 15:25 -0500
                                          Re: Hello World Nigel Wade <nmw@ion.le.ac.uk> - 2015-03-10 11:23 +0000
                                      Re: Hello World Alan Meyer <ameyer2@yahoo.com> - 2015-03-09 16:37 -0400
                                      Re: Hello World Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-03-09 21:58 +0000
                                        Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-09 18:09 -0500
                                          Re: Hello World Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-03-10 23:43 +0000
                                          Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-10 19:50 -0400
                                    Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-09 15:17 -0500
                                      Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-09 16:19 -0500
                                        Re: Hello World Alan Meyer <ameyer2@yahoo.com> - 2015-03-09 16:27 -0400
                                        Re: Hello World Nigel Wade <nmw@ion.le.ac.uk> - 2015-03-10 15:18 +0000
                                      Re: Hello World Your Name <YourName@YourISP.com> - 2015-03-10 13:31 +1300
                          Re: Hello World Your Name <YourName@YourISP.com> - 2015-03-10 09:29 +1300
                            Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-09 16:29 -0500
                  Re: Hello World Your Name <YourName@YourISP.com> - 2015-03-09 13:26 +1300
          Re: Hello World Sunshine <sunshine@my.antispam.invalid> - 2015-03-08 16:08 -0500
            Re: Hello World nospam <nospam@nospam.invalid> - 2015-03-08 17:23 -0500
        Re: Hello World Doc O'Leary  <droleary@2usenet2014.subsume.com> - 2015-03-09 03:26 +0000
    Re: Hello World Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-03-09 14:20 +0000
      Re: Hello World BugHunter <bughunter@com.invalid> - 2015-03-09 15:42 +0100
        Re: Hello World Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-03-09 19:05 +0000
      Re: Hello World Michelle Steiner <michelle@michelle.org> - 2015-03-09 08:12 -0700
      Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-09 17:48 +0000
        Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-09 18:30 +0000
          Re: Hello World BugHunter <bughunter@com.invalid> - 2015-03-09 19:35 +0100
        Re: Hello World Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-03-09 19:11 +0000
          Re: Hello World Ed Cryer <ed@somewhere.in.the.uk> - 2015-03-10 12:16 +0000
        Re: Hello World Your Name <YourName@YourISP.com> - 2015-03-10 09:35 +1300
        Re: Hello World "HankG" <hgxrp@yahoo.com> - 2015-03-11 13:58 -0400

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#46192

On 3/9/2015 1:32 PM, Ed Cryer wrote:

> People tell me that C++ is the best general-purpose language.

To which others will respond that it's an abomination, and you should 
use ANSI C.  :-)

It largely depends on what you're writing.  If you are writing systems 
software, you use a language like C/C++ that compiles to native machine 
code.  If you are writing an application, the equation changes.

(And you must be aware of compiler differences.  When Mozilla was 
creating what became Firefox, they used C++ and wanted portable code. 
There was an amusing developer's document that had lots of admonitions 
to the effect of "Just because it works in Microsoft Visual C++, don't 
assume it works elsewhere."  A particular problem child was the C++ 
compiler shipped with HP-UX.)

On Android, the development language is Java, as implemented by the 
Dalvik runtime.  iOS, as mentioned, expects Objective-C or Swift.  On 
Windows, Linux, or OS/X, you might use Python.

The advantage to Java and Python is that they compile to an intermediate 
representation targeted at the virtual machine implemented by the 
language runtime.  It's possible to write and compile Java, for example, 
on Windows, and run the code on a different platform.  The output from 
Java compilation is the same regardless of what you compiled it on.  I 
have IBM's Eclipse IDE written in Java here.  I run the *same* binary on 
Windows and Linux.

Modern hardware is fast and powerful enough that you can write in 
something like Python and get good enough performance that you don't 
*have* to compile to native code.

> Ed
______
Dennis

[toc] | [prev] | [next] | [standalone]

#46195

In article <mdkqd4$u3s$1@dont-email.me>, DMcCunney
<dennis.mccunney@gmail.com> wrote:

> > People tell me that C++ is the best general-purpose language.
> 
> To which others will respond that it's an abomination, and you should 
> use ANSI C.  :-)

nonsense. c++ fixes all the crap that ansi c is.

> It largely depends on what you're writing.  If you are writing systems 
> software, you use a language like C/C++ that compiles to native machine 
> code.  If you are writing an application, the equation changes.

no it doesn't.

apps that are native code run faster and give a much better user
experience. 

> (And you must be aware of compiler differences.  When Mozilla was 
> creating what became Firefox, they used C++ and wanted portable code. 
> There was an amusing developer's document that had lots of admonitions 
> to the effect of "Just because it works in Microsoft Visual C++, don't 
> assume it works elsewhere."  A particular problem child was the C++ 
> compiler shipped with HP-UX.)

microsoft's compiler was not standards compliant.

blame them, not the language.

> On Android, the development language is Java, as implemented by the 
> Dalvik runtime. 

dalvik is what android used to use. it's now art.

> iOS, as mentioned, expects Objective-C or Swift.  On 
> Windows, Linux, or OS/X, you might use Python.

python is not a good choice for apps, except maybe very simple ones.

> The advantage to Java and Python is that they compile to an intermediate 
> representation targeted at the virtual machine implemented by the 
> language runtime.  It's possible to write and compile Java, for example, 
> on Windows, and run the code on a different platform.  The output from 
> Java compilation is the same regardless of what you compiled it on.  I 
> have IBM's Eclipse IDE written in Java here.  I run the *same* binary on 
> Windows and Linux.

that doesn't work well in practice.

> Modern hardware is fast and powerful enough that you can write in 
> something like Python and get good enough performance that you don't 
> *have* to compile to native code.

except that other developers *are* compiling to native code, which
means their apps will be that much better.

[toc] | [prev] | [next] | [standalone]

#46209

On 3/9/2015 4:07 PM, nospam wrote:
...
>> It largely depends on what you're writing.  If you are writing systems
>> software, you use a language like C/C++ that compiles to native machine
>> code.  If you are writing an application, the equation changes.
>
> no it doesn't.
>
> apps that are native code run faster and give a much better user
> experience.

If a task completes in 3 milliseconds instead of 30, is that a much 
better user experience?  Bear in mind that a blink of an eye is 300 
milliseconds.

If a program generates a web page in 500 milliseconds, but it takes 5 
seconds to stream all of the associated resources (images, etc.) to a 
user's browser and have the browser render it, would it really matter if 
we got the server time down to 100 milliseconds, or 10 milliseconds, or 
even 1 millisecond?

>> iOS, as mentioned, expects Objective-C or Swift.  On
>> Windows, Linux, or OS/X, you might use Python.
>
> python is not a good choice for apps, except maybe very simple ones.

It turns out that there is a great quantity of production code written 
in Python.  I've used it on projects where I believe it saved hundreds 
of thousands of dollars in programmer time while producing applications 
that ran at least as fast as the users wanted.

Java has a lot of runtime overhead not associated with C or C++ but I 
have seen benchmarks showing that, for many applications, using the 
recent Java runtimes, it's just about as fast.  I believe that I could 
write most big applications twice as quickly in Java as in C++, and I 
have a lot of experience with both.

>> The advantage to Java and Python is that they compile to an intermediate
>> representation targeted at the virtual machine implemented by the
>> language runtime.  It's possible to write and compile Java, for example,
>> on Windows, and run the code on a different platform.  The output from
>> Java compilation is the same regardless of what you compiled it on.  I
>> have IBM's Eclipse IDE written in Java here.  I run the *same* binary on
>> Windows and Linux.
>
> that doesn't work well in practice.

>> Modern hardware is fast and powerful enough that you can write in
>> something like Python and get good enough performance that you don't
>> *have* to compile to native code.
>
> except that other developers *are* compiling to native code, which
> means their apps will be that much better.

Maybe, maybe not.  It depends how mush extra work is required to develop 
the programs and how much extra work and time it takes to fix bugs, add 
enhancements, document code, and bring new programmers on board.  In my 
experience C++ is one of the harder languages for all of those issues.

Performance is only one of the criteria for selecting a programming 
language, and it can become pretty unimportant if an implementation in a 
language that's cheaper and easier to develop, debug, and maintain is 
acceptably fast.

     Alan

[toc] | [prev] | [next] | [standalone]

#46227

Okay, so one time? In band camp? Alan Meyer <ameyer2@yahoo.com> was all, like:
> On 3/9/2015 4:07 PM, nospam wrote:
> ...
>>> It largely depends on what you're writing.  If you are writing systems
>>> software, you use a language like C/C++ that compiles to native machine
>>> code.  If you are writing an application, the equation changes.
>>
>> no it doesn't.
>>
>> apps that are native code run faster and give a much better user
>> experience.

> If a task completes in 3 milliseconds instead of 30, is that a much 
> better user experience?  Bear in mind that a blink of an eye is 300 
> milliseconds.

> If a program generates a web page in 500 milliseconds, but it takes 5 
> seconds to stream all of the associated resources (images, etc.) to a 
> user's browser and have the browser render it, would it really matter if 
> we got the server time down to 100 milliseconds, or 10 milliseconds, or 
> even 1 millisecond?

No, but it matters a whole hell of a lot if you go over 400ms.

>> python is not a good choice for apps, except maybe very simple ones.

> It turns out that there is a great quantity of production code written 
> in Python.  I've used it on projects where I believe it saved hundreds 
> of thousands of dollars in programmer time while producing applications 
> that ran at least as fast as the users wanted.

There is a (lot* of code written in python. I don't know how much of
that is "apps" but a lot of OSS is in python. Of course, a lot is in
perl, so there's no accounting for taste in programming languages.

-- 
http://2blog.kreme.com
Beautiful dawn / Lights up the shore for me / There is nothing else in the
world I'd rather see with you.

[toc] | [prev] | [next] | [standalone]

#46241

In article <54FE0069.7050003@yahoo.com>, Alan Meyer <ameyer2@yahoo.com>
wrote:

> >> It largely depends on what you're writing.  If you are writing systems
> >> software, you use a language like C/C++ that compiles to native machine
> >> code.  If you are writing an application, the equation changes.
> >
> > no it doesn't.
> >
> > apps that are native code run faster and give a much better user
> > experience.
> 
> If a task completes in 3 milliseconds instead of 30, is that a much 
> better user experience?  Bear in mind that a blink of an eye is 300 
> milliseconds.

and what if a task takes 0.5 seconds versus 2 seconds?

what if the frame rate of a game is 20-30 fps versus 60 fps?

what if scrolling lags because it's redrawing content and can't keep up?

> If a program generates a web page in 500 milliseconds, but it takes 5 
> seconds to stream all of the associated resources (images, etc.) to a 
> user's browser and have the browser render it, would it really matter if 
> we got the server time down to 100 milliseconds, or 10 milliseconds, or 
> even 1 millisecond?

there's a lot more to apps than just browser rendering.

> >> iOS, as mentioned, expects Objective-C or Swift.  On
> >> Windows, Linux, or OS/X, you might use Python.
> >
> > python is not a good choice for apps, except maybe very simple ones.
> 
> It turns out that there is a great quantity of production code written 
> in Python.  I've used it on projects where I believe it saved hundreds 
> of thousands of dollars in programmer time while producing applications 
> that ran at least as fast as the users wanted.

there's plenty of code in c++, if not more than python.

> Java has a lot of runtime overhead not associated with C or C++ but I 
> have seen benchmarks showing that, for many applications, using the 
> recent Java runtimes, it's just about as fast. 

what matters more is the algorithm used, not the choice of language.

> I believe that I could 
> write most big applications twice as quickly in Java as in C++, and I 
> have a lot of experience with both.

unlikely.

go write photoshop in java, see how well that works out.

someone actually tried to do that once and it was *horrible*. 

> >> Modern hardware is fast and powerful enough that you can write in
> >> something like Python and get good enough performance that you don't
> >> *have* to compile to native code.
> >
> > except that other developers *are* compiling to native code, which
> > means their apps will be that much better.
> 
> Maybe, maybe not.  It depends how mush extra work is required to develop 
> the programs and how much extra work and time it takes to fix bugs, add 
> enhancements, document code, and bring new programmers on board.  In my 
> experience C++ is one of the harder languages for all of those issues.

nonsense. c++ makes it very hard to make stupid errors that are quite
common in c and many other languages. 

> Performance is only one of the criteria for selecting a programming 
> language, and it can become pretty unimportant if an implementation in a 
> language that's cheaper and easier to develop, debug, and maintain is 
> acceptably fast.

depends on the app.

some apps need high performance. others don't.

[toc] | [prev] | [next] | [standalone]

#46247

nospam wrote, on Mon, 09 Mar 2015 22:36:19 -0400:

> go write photoshop in java, see how well that works out.

I worked in the software industry for a few decades, and nobody 
but nobody would write the stuff our software did, in anything 
like java. It would be an abomination from the start.

One startup tried ruby-on-rails, and had to rewrite EVERTHYING
from scratch.

Inefficiency on top of inefficiency in spades.

But, luckily, an "app" isn't very sophisticated compared to what
runs on Linux platforms in the industrial environment.

[toc] | [prev] | [next] | [standalone]

#46258

In article <mdmr7v$a9k$1@solani.org>, Tony Cito
<tonycito@this.is.invalid> wrote:

> But, luckily, an "app" isn't very sophisticated compared to what
> runs on Linux platforms in the industrial environment.

'app' is short for application. there's nothing about the name app that
means it's a toy.

apps can be extremely sophisticated. many of them are. some even run on
linux.

[toc] | [prev] | [next] | [standalone]

#46238

On 3/9/2015 4:07 PM, nospam wrote:
> In article <mdkqd4$u3s$1@dont-email.me>, DMcCunney
> <dennis.mccunney@gmail.com> wrote:
>
>>> People tell me that C++ is the best general-purpose language.
>>
>> To which others will respond that it's an abomination, and you should
>> use ANSI C.  :-)
>
> nonsense. c++ fixes all the crap that ansi c is.

<blink>  Do remember that the earliest versions of C++ were implemented 
at Bell Labs as cfront, which translated C++ to C, for compilation by 
the Unix C compiler, cc.  Native code compilation came later.

There's still an awful lot of C code in the wild.

>> It largely depends on what you're writing.  If you are writing systems
>> software, you use a language like C/C++ that compiles to native machine
>> code.  If you are writing an application, the equation changes.
>
> no it doesn't.
>
> apps that are native code run faster and give a much better user
> experience.

Native code may be faster, but user experience is based on many things, 
and speed is only one.  From use user's perspective, the question isn't 
"How fast is it", it's "Is it fast *enough?*"  If it is, the speed 
advantage from native code is irrelevant, and the easier development and 
shorter development cycles using something like Java or Python become 
compelling.

>> (And you must be aware of compiler differences.  When Mozilla was
>> creating what became Firefox, they used C++ and wanted portable code.
>> There was an amusing developer's document that had lots of admonitions
>> to the effect of "Just because it works in Microsoft Visual C++, don't
>> assume it works elsewhere."  A particular problem child was the C++
>> compiler shipped with HP-UX.)
>
> microsoft's compiler was not standards compliant.
>
> blame them, not the language.

I blame programmers who weren't versed in the standard, and thought what 
Visual C++ did was the way they all did it.

And even if two products are theoretically standards compliant, you can 
find differences in how they *implement* the standard.  Depending upon 
the standard and how it is written, both may be arguably standards 
compliant yet incompatible.

>> On Android, the development language is Java, as implemented by the
>> Dalvik runtime.
>
> dalvik is what android used to use. it's now art.

Still a Java runtime, but noted.

>> iOS, as mentioned, expects Objective-C or Swift.  On
>> Windows, Linux, or OS/X, you might use Python.
>
> python is not a good choice for apps, except maybe very simple ones.

<giggle>

>> The advantage to Java and Python is that they compile to an intermediate
>> representation targeted at the virtual machine implemented by the
>> language runtime.  It's possible to write and compile Java, for example,
>> on Windows, and run the code on a different platform.  The output from
>> Java compilation is the same regardless of what you compiled it on.  I
>> have IBM's Eclipse IDE written in Java here.  I run the *same* binary on
>> Windows and Linux.
>
> that doesn't work well in practice.

It's not easy to achieve, but *is* achievable.  See my example of 
Eclipse above.  And if you do it, it's a lot faster and simpler to 
develop than writing in something like C++, getting it portable, then 
cross compiling for different architectures.

>> Modern hardware is fast and powerful enough that you can write in
>> something like Python and get good enough performance that you don't
>> *have* to compile to native code.
>
> except that other developers *are* compiling to native code, which
> means their apps will be that much better.

You may picture me rolling on the floor and laughing hysterically.

As an example, an app used daily here is Calibre, from
http://calibre-ebook.com.

Calibre is a "Swiss Army Knife for eBooks", written by an Indian 
developer named Kovid Goyal.  Kovid began writing it while a PhD 
candidate in computer science.  He had a Sony Reader which used a 
proprietary eBook format called BBLF, and the only place you could get 
content for the reader was the Sony Store.  What became Calibre began as 
a tool to get content into the BBLF format so he could read it in his 
device.

It has grown since.  These days the principal use is to create and 
maintain an eBook library, using the public domain SQLite product as the 
underlying DBMS.  You can add books to the library from online or local 
sources, and go out to various sites on the Internet to gather the 
metadata for the book.  Calibre also has comprehensive conversions 
facilities, so if you have, say, an eBook in ePub format, and want to 
read it on a device that uses Amazon's Mobipocket format instead, 
Calibre can convert it for you.  Recent versions are steadily adding 
features to edit ePub files, taking over from the no longer developed 
Sigil program.

It's available for 32 and 64bit Windows, a portable Windows version, 
Linux, and OS/X.  I have it here under Windows and Ubuntu.  Kovid has a 
new point release weekly, fixing bugs and adding features.

(And it has become his job.  It's open source under the GPL, but you can 
donate to him if you're happy, and enough people have been that Kovid 
can develop Calibre full time.)

It's written in Python.

The only other app I am aware of comparable to Calibre is Readerware, 
and *that's* written in *Java*.

There's an awful lot of production code out there in Python, with more 
all the time. As mentioned, modern hardware is fast enough that you 
don't necessarily have to compile to native code to get adequate 
performance.
______
Dennis

[toc] | [prev] | [next] | [standalone]

#46259

In article <mdla9p$jeo$1@dont-email.me>, DMcCunney
<dennis.mccunney@gmail.com> wrote:

> >>> People tell me that C++ is the best general-purpose language.
> >>
> >> To which others will respond that it's an abomination, and you should
> >> use ANSI C.  :-)
> >
> > nonsense. c++ fixes all the crap that ansi c is.
> 
> <blink>  Do remember that the earliest versions of C++ were implemented 
> at Bell Labs as cfront, which translated C++ to C, for compilation by 
> the Unix C compiler, cc.  Native code compilation came later.

so what? that was a very, very long time ago.

today, modern c++ compilers are better than c compilers for many
reasons and produce faster code with fewer bugs. everyone wins.

> There's still an awful lot of C code in the wild.

so what? there's an awful lot of cobol code in the wild too.

> >> It largely depends on what you're writing.  If you are writing systems
> >> software, you use a language like C/C++ that compiles to native machine
> >> code.  If you are writing an application, the equation changes.
> >
> > no it doesn't.
> >
> > apps that are native code run faster and give a much better user
> > experience.
> 
> Native code may be faster, but user experience is based on many things, 
> and speed is only one.  From use user's perspective, the question isn't 
> "How fast is it", it's "Is it fast *enough?*"  If it is, the speed 
> advantage from native code is irrelevant, and the easier development and 
> shorter development cycles using something like Java or Python become 
> compelling.

speed is a key component. user interface design is another but that has
nothing to do with the choice of language.

> >> (And you must be aware of compiler differences.  When Mozilla was
> >> creating what became Firefox, they used C++ and wanted portable code.
> >> There was an amusing developer's document that had lots of admonitions
> >> to the effect of "Just because it works in Microsoft Visual C++, don't
> >> assume it works elsewhere."  A particular problem child was the C++
> >> compiler shipped with HP-UX.)
> >
> > microsoft's compiler was not standards compliant.
> >
> > blame them, not the language.
> 
> I blame programmers who weren't versed in the standard, and thought what 
> Visual C++ did was the way they all did it.

blame microsoft for that. microsoft intentionally twisted the standard
for lock-in. 

> And even if two products are theoretically standards compliant, you can 
> find differences in how they *implement* the standard.  Depending upon 
> the standard and how it is written, both may be arguably standards 
> compliant yet incompatible.

sometimes.

> >> On Android, the development language is Java, as implemented by the
> >> Dalvik runtime.
> >
> > dalvik is what android used to use. it's now art.
> 
> Still a Java runtime, but noted.
> 
> >> iOS, as mentioned, expects Objective-C or Swift.  On
> >> Windows, Linux, or OS/X, you might use Python.
> >
> > python is not a good choice for apps, except maybe very simple ones.
> 
> <giggle>

you haven't written very many apps then.

> >> The advantage to Java and Python is that they compile to an intermediate
> >> representation targeted at the virtual machine implemented by the
> >> language runtime.  It's possible to write and compile Java, for example,
> >> on Windows, and run the code on a different platform.  The output from
> >> Java compilation is the same regardless of what you compiled it on.  I
> >> have IBM's Eclipse IDE written in Java here.  I run the *same* binary on
> >> Windows and Linux.
> >
> > that doesn't work well in practice.
> 
> It's not easy to achieve, but *is* achievable.  See my example of 
> Eclipse above.  And if you do it, it's a lot faster and simpler to 
> develop than writing in something like C++, getting it portable, then 
> cross compiling for different architectures.

eclipse is awful. 

> >> Modern hardware is fast and powerful enough that you can write in
> >> something like Python and get good enough performance that you don't
> >> *have* to compile to native code.
> >
> > except that other developers *are* compiling to native code, which
> > means their apps will be that much better.
> 
> You may picture me rolling on the floor and laughing hysterically.
> 
> As an example, an app used daily here is Calibre, from
> http://calibre-ebook.com.

calibre is a steaming pile of shit and has a user interface only a
mother could love. 

if that's the best example you can come up with, you've proved my point.

[toc] | [prev] | [next] | [standalone]

#46261

nospam wrote:
> In article <mdla9p$jeo$1@dont-email.me>, DMcCunney
> <dennis.mccunney@gmail.com> wrote:

> today, modern c++ compilers are better than c compilers for many
> reasons and produce faster code with fewer bugs. everyone wins.

In many cases yes, assuming there's a C++ compiler for your target platform.

>> There's still an awful lot of C code in the wild.
>
> so what? there's an awful lot of cobol code in the wild too.

And there's a reason who both continue to exist.

>>> apps that are native code run faster and give a much better user
>>> experience.
>>
>> Native code may be faster, but user experience is based on many things,
>> and speed is only one.  From use user's perspective, the question isn't
>> "How fast is it", it's "Is it fast *enough?*"  If it is, the speed
>> advantage from native code is irrelevant, and the easier development and
>> shorter development cycles using something like Java or Python become
>> compelling.
>
> speed is a key component. user interface design is another but that has
> nothing to do with the choice of language.

You use the language suited from what you are trying to write.  If you 
are writing systems software, you probably use C++ (though if 
parallelism is a concern, you might use Go, and for systems software you 
might try Rust instead.)

An old friend develops software for financial applications.  He uses K. 
  He claims (and I have no reason to doubt him) that he can deliver 
completed applications in the time it takes developers in other 
languages to estimate how long it will take to develop the requested 
application in the language they use.

Different languages address different problem domains.

>>> microsoft's compiler was not standards compliant.
>>>
>>> blame them, not the language.
>>
>> I blame programmers who weren't versed in the standard, and thought what
>> Visual C++ did was the way they all did it.
>
> blame microsoft for that. microsoft intentionally twisted the standard
> for lock-in.

I blame Microsoft for twisting the standard (and in various instances 
trying to make what *they* chose to do the standard.) That does not 
excuse a programmer working in an area where the standard is important 
not being *aware* that MS C++ was not standards compliant, and that code 
that worked in it might not build elsewhere.

>>>> I have IBM's Eclipse IDE written in Java here.  I run the *same* binary on
>>>> Windows and Linux.
>>>
>>> that doesn't work well in practice.
>>
>> It's not easy to achieve, but *is* achievable.  See my example of
>> Eclipse above.  And if you do it, it's a lot faster and simpler to
>> develop than writing in something like C++, getting it portable, then
>> cross compiling for different architectures.
>
> eclipse is awful.

There are many IDEs.  Each has devoted adherents.  The advantage to 
Eclipse is that it's cross platform and extensible, can support 
development in pretty much any language, and looks and acts the same 
where ever you run it.  There are reasons it has become the most used 
IDE.  (I just encountered two different software development kits from 
two different outfits targeting the embedded space that used Eclipse and 
GCC as the basis for their toolchain.)

Understood you don't like it, but don't assume you're representative.

>>>> Modern hardware is fast and powerful enough that you can write in
>>>> something like Python and get good enough performance that you don't
>>>> *have* to compile to native code.
>>>
>>> except that other developers *are* compiling to native code, which
>>> means their apps will be that much better.
>>
>> You may picture me rolling on the floor and laughing hysterically.
>>
>> As an example, an app used daily here is Calibre, from
>> http://calibre-ebook.com.
>
> calibre is a steaming pile of shit and has a user interface only a
> mother could love.

Point at something else you would use instead that can do the same things.

I don't care if it's written in C++ or not.

I don't find the UI a problem, and learned to get around it in quite 
quickly, thank you.

> if that's the best example you can come up with, you've proved my point.

For the record, I don't object to C++, and think it's a fine language. 
I just don't think it's the only fine language, or the only or even the 
best choice in a language.  It depends entirely on the task at hand.
______
Dennis

[toc] | [prev] | [next] | [standalone]

#46264

On 3/9/2015 7:28 PM, DMcCunney wrote:
...
>> python is not a good choice for apps, except maybe very simple ones.
>
> <giggle>

An eloquent rejoinder.

...
> As an example, an app used daily here is Calibre, from
> http://calibre-ebook.com.

That's an application I have used many times.  It's a sophisticated 
program with a lot of capability.

nospam:

Obviously, you're right that some programs really need to be written in 
C++.  Others really need to be written even lower in C, and there are 
some, such as hardware drivers and real-time networking, 
instrumentation, etc. programs that should sometimes be written in 
assembler.

Some big applications also require lower level tools.  I heard, for 
example, that Microsoft attempted to re-write Office in C# but gave up. 
  The performance was inadequate.

However it's as much a mistake to think that all programs should be 
written in C++ or similar languages as it was for the assembler 
die-hards to resist the incursion of PL/1, C, Pascal, etc.

The same debate was waged by some old programmers who saw no possible 
value in database management systems.  They said, "I can write a program 
to store and retrieve data by using track and sector geometry that will 
run much faster than your DBMS."  They were right.  But they couldn't 
build complex information systems much less make them portable across 
different hardware.

The general rule that the industry has adopted, rightly so I think, is 
to use the highest level, highest functionality tools available to meet 
the performance requirements of the application.


I know that shouldn't be writing this stuff, but it's fun to re-visit 
the battles waged 20 years ago - especially since I already know who the 
winners were.

    Alan

[toc] | [prev] | [next] | [standalone]

#46200

Okay, so one time? In band camp? DMcCunney <dennis.mccunney@gmail.com> was all, like:
> On 3/9/2015 1:32 PM, Ed Cryer wrote:

>> People tell me that C++ is the best general-purpose language.

> To which others will respond that it's an abomination, and you should 
> use ANSI C.  :-)

I think that ship has sailed.

Very few people would tell you to use C++, though they might tell you to
LEARN C++. This is good advice.

If you want to program for the ipad (as this newsgroup would suggest),
learn Swift.


-- 
http://2blog.kreme.com
I WILL NOT CARVE GODS Bart chalkboard Ep. 8F11

[toc] | [prev] | [next] | [standalone]

#46196

In article <mdklh0$8r7$1@dont-email.me>, Ed Cryer
<ed@somewhere.in.the.uk> wrote:

> People tell me that C++ is the best general-purpose language.

for a lot of things it is, but not everything. 

the choice of language makes very little difference, except where it's
required, such as java for android and at least some obj-c/swift in ios
(but it doesn't have to be all).

[toc] | [prev] | [next] | [standalone]

#46186

On 3/9/2015 11:14 AM, Sunshine wrote:
> On Mon, 09 Mar 2015 11:10:42 -0500, nospam wrote:
>
>> it's very different.
>
> I doubt it's *any* different (meaningfully).
>
> But that's what I'm going to need to learn.
>
> I'll start with the tutorials for Android which seem more
> amenable to my hardware although I can get a hold of a mac
> if that's what I need for iOS.

I also started on IBM mainframes, programming in PL/1 and COBOL.  I'm 
still programming today - mainly Python, PHP and C++.  I've done a lot 
of Java but only minimal playing around with Android.

There are some BIG differences in the new style of programming needed 
for Android, and I presume also for iOS.

One obvious one is graphics and animation.  I never cared about that 
stuff in the mainframe world but it's a key part of Android and iOS.

Another one is object orientation (OO).  You need to learn some new 
concepts that weren't built-in to the older languages.

A huge one is APIs.  In the old days, if I needed a hash table, a tree 
structure, or a linked list, I wrote it myself.  Today it all comes out 
of APIs that are built-in to the language and/or environment.  If you 
want to utilize or control any part of the physical devices you're 
using: screen, virtual keyboard, phone, GPS, sound, proximity sensor, 
file system, you name it, you must use the APIs.  But that's just the 
obvious stuff.  You also have to interact with subtler issues like the 
permission system, the network, services, and many others.  There are 
literally thousands of classes, methods, fields and interfaces (think 
OO) that you don't need to fully master, but you do need to know enough 
to find the ones that you should use and not try to re-invent them.

Then there's the problem of working with modern integrated development 
environments, debuggers, and emulators.  It isn't just a text editor and 
a compiler any more.

If you want an interesting challenge, go for it.  But don't kid yourself 
about how much or little you'll need to learn.

As for where to go for information, there must be a hundred Android 
development books out there and quite a few web sources of information 
and tutorials.  If you buy a book, look at reviews on Amazon and be sure 
to get something recent since the platform has developed pretty quickly.

You'll also want to use a reasonably hefty PC.  Running an emulator 
takes a big bite out of memory and processing power.  You can get by 
without a lot of hardware but you may wait a lot for things to happen.

    Alan

[toc] | [prev] | [next] | [standalone]

#46206

On Mon, 09 Mar 2015 13:56:30 -0400, Alan Meyer wrote:

> 
> Another one is object orientation (OO).  You need to learn some new 
> concepts that weren't built-in to the older languages.

I've never understood what "object oriented" meant.
I mean, everything is an object, to me. 
In Fortran, we had subroutines. 
In Assembly language, we jumped to a memory location.
In C, we had variables.

Anyway, they're *all* objects, in a way. 
So, I never understood what's different about Object Oriented Programming.
It's just "programming", with its own syntax issues (heck, at least
it's not big endian versus little endian, for example).

[toc] | [prev] | [next] | [standalone]

#46210

In article
<cea0a$54fdff72$43da7656$24852@nntpswitch.blueworldhosting.com>,
Sunshine <sunshine@my.antispam.invalid> wrote:

> > Another one is object orientation (OO).  You need to learn some new 
> > concepts that weren't built-in to the older languages.
> 
> I've never understood what "object oriented" meant.

then it's time to learn something new.

[toc] | [prev] | [next] | [standalone]

#46214

On Mon, 09 Mar 2015 16:19:54 -0500, nospam wrote:

>> I've never understood what "object oriented" meant.
> 
> then it's time to learn something new.

I guess, if I find out that an "object" isn't just a word for
something that every programming language has to do anyway, 
then, I'll have learned sumphun'.

[toc] | [prev] | [next] | [standalone]

#46243

On 09/03/15 20:25, Sunshine wrote:
> On Mon, 09 Mar 2015 16:19:54 -0500, nospam wrote:
>
>>> I've never understood what "object oriented" meant.
>>
>> then it's time to learn something new.
>
> I guess, if I find out that an "object" isn't just a word for
> something that every programming language has to do anyway,
> then, I'll have learned sumphun'.
>

It isn't.

Look, you already learned something new!

[toc] | [prev] | [next] | [standalone]

#46220

On 3/9/2015 4:15 PM, Sunshine wrote:
> On Mon, 09 Mar 2015 13:56:30 -0400, Alan Meyer wrote:
>
>>
>> Another one is object orientation (OO).  You need to learn some new
>> concepts that weren't built-in to the older languages.
>
> I've never understood what "object oriented" meant.
> I mean, everything is an object, to me.
> In Fortran, we had subroutines.
> In Assembly language, we jumped to a memory location.
> In C, we had variables.
>
> Anyway, they're *all* objects, in a way.
> So, I never understood what's different about Object Oriented Programming.
> It's just "programming", with its own syntax issues (heck, at least
> it's not big endian versus little endian, for example).
>

When I first began object oriented programming my reaction was the same 
as yours.  What's the big deal, I thought.  We've had structures in C 
since the 1970's and records in COBOL maybe since the 50's.

But there's more to it than that.  Once you start getting into 
inheritance, sometimes multiple inheritance, polymorphism, "interfaces", 
"abstract" classes, "virtual" classes, public private and protected 
access, etc. you find that there really are some new programming 
paradigms here.

If you pick up a book on Java, C++, C# or another OOP language, your 
first reaction may still be, why is there all this exotic nomenclature 
for things we could always do?  But as you read on and start writing 
code, I think you may find some very interesting stuff and some usefully 
different ways to think about programming.

I suggest you approach it as an opportunity to learn something new and 
interesting.  I don't think you'll be disappointed.

    Alan

[toc] | [prev] | [next] | [standalone]

#46226

Okay, so one time? In band camp? Sunshine <sunshine@my.antispam.invalid> was all, like:
> On Mon, 09 Mar 2015 13:56:30 -0400, Alan Meyer wrote:

>> 
>> Another one is object orientation (OO).  You need to learn some new 
>> concepts that weren't built-in to the older languages.

> I've never understood what "object oriented" meant.

Then you're not much of a programmer. <https://en.wikipedia.org/wiki/Object-oriented_programming>

> I mean, everything is an object, to me.

No.

> In Fortran, we had subroutines.

Not at all the same thing as OO.

print address.number + address.street

Where address is an object that contains classes number and street
(and maybe others as well).

> In Assembly language, we jumped to a memory location.
> In C, we had variables.

> Anyway, they're *all* objects, in a way. 

Not in the way of object oriented, no.

> It's just "programming", with its own syntax issues (heck, at least
> it's not big endian versus little endian, for example).

It is not *just* programming. Duplicating the advantages of OO in a
non-OO language is either tedious and difficult or just impossible.

-- 
http://2blog.kreme.com
Turning and turning in the widening gyre
The falcon cannot hear the falconer;

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.mobile.ipad

csiph-web