Active Topics
-
Maemo repository (8)
to Community by Maemish - 1 day, 1 hr ago -
Porting apps to Leste (44)
to Maemo 7 / Leste by norayr - 1 day, 6 hrs ago -
List of well performing apps on Leste (35)
to Maemo 7 / Leste by smatkovi - 4 days, 3 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (13)
to SailfishOS by edp17 - 5 days, 1 hr ago -
Sailfish OS for the Samsung Galaxy Note 4 (SM-N910C) - (treltexx) (79)
to SailfishOS by edp17 - 5 days, 1 hr ago -
U-Boot for Nokia RX-51 with BootMenu (updated version 2012.10-rc3-1) (843)
to Alternatives by Arno_11 - 5 days, 6 hrs ago - more...
|
2009-11-09
, 14:03
|
|
Posts: 271 |
Thanked: 220 times |
Joined on Sep 2009
|
#22
|
Originally Posted by Fargus
Um, no...I'm quite sure I specified Python.
Like Java you mean as that is SUCH an efficient system.
The ONLY reason for such environments is to increase programmer productivity by reducing the time & engineering ability required to produce software. This doesn't mean that such programmers are less talented, just that they spend less effort in producing a final application using such means.
This situation is exactly the reason higher level languages were developed in the first place (assembler anyone?).
If you want a quick release to the world then interpretted languages are great (see how VB took over the corporate app world); if you want speed and efficiency then you need to put more effort and discipline in & manage the resources yourself. Garbage collection in language was introduced purely for development efficiency, not runtime.
Just look at the myriad of buffer overflows, memory leaks, and all the other fun toys that C and C++ have given us over the years. But hey, since you're perfect and infallible...I'm sure advancements like Python (among others..which can of course be compile to native code) are way beneath you
You know, there's a reason that MS developers aren't allowed to use C++ anymore for the most part. "Put more effort and discipline" sounds good on paper, but in reality it becomes nearly impossible to get it "perfect" (which is what is required) on large projects when you have to manage resources yourself.It's funny that you mention C/C++ as an advancement over assembler...yet fail to comprehend the benefits of JIT languages like Python over C/C++. LOL...careful you don't run into anything with those blinders on.
Last edited by texaslabrat; 2009-11-09 at 14:13.
 |
|
2009-11-09
, 14:11
|
|
Posts: 1,217 |
Thanked: 446 times |
Joined on Oct 2009
@ Bedfordshire, UK
|
#23
|
Originally Posted by texaslabrat
I have worked with Assembler, C, C++ and projects with Python. They are fine with higher powered systems but I believe that the thread was talking about mobile devices. Benefits are all reletive and depend on the environment used and the aims of the project.
Um, no...I'm quite sure I specified Python.
Just look at the myriad of buffer overflows, memory leaks, and all the other fun toys that C and C++ have given us over the years. But hey, since you're perfect and infallible...I'm sure advancements like Python (among others..which can of course be compile to native code) are way beneath you
It's funny that you mention C/C++ as an advancement over assembler...yet fail to comprehend the benefits of JIT languages like Python over C/C++. LOL...careful you don't run into anything with those blinders on.
Much as you might like JIT systems the documented fact is that they were developed to reduce developer time, not resource usage. The idea is that processing power will over come that issue quickly.
The buffer leaks etcetera do still occur with JIT systems though less frequent. The problems with memory leaks are the fault of the programmers in question, not the language and hence I refer you back to lack of engineering. This is not about being perfect, just about being systematic and using engineering disciplines.
I have checked and can't see where I mentioned C/C++ as being an advancement over assembler. I probably said that they were developed as a higher level language. No one language is better than another for all situations, same as methodologies and architectures.
I do seem to remember that you mentioned using a JIT to reduce memory sapping leaks etceteras but the JIT itself is also a resource requirment.
Last edited by Fargus; 2009-11-09 at 14:18.
|
|
2009-11-09
, 14:21
|
|
Posts: 271 |
Thanked: 220 times |
Joined on Sep 2009
|
#24
|
Originally Posted by Fargus
Well, same here..I've worked in just about everything under the sun at one time or another...and the thing that I brought away from that is that leaving memory management and garbage collection to the developers is a bugzilla event waiting to happen.
I have worked with Assembler, C, C++ and projects with Python. They are fine with higher powered systems but I believe that the thread was talking about mobile devices. Benefits are all reletive and depend on the environment used and the aims of the project.
Much as you might like JIT systems the documented fact is that they were developed to reduce developer time, not resource usage. The idea is that processing power will over come that issue quickly.
The buffer leaks etcetera do still occur with JIT systems though less frequent. The problems with memory leaks are the fault of the programmers in question, not the language and hence I refer you back to lack of engineering. This is not about being perfect, just about being systematic and using engineering disciplines.
And yes, there are some problems with even JIT languages (guess what language the JIT compiler was written in LOL), but to fix those is a swapping of the run time rather than re-writing every application ever distributed.
And yes, it is about being "perfect" because no amount of engineering discipline can overcome the propensity to commit typos after 10's of thousands of lines of code. That's human nature...and has zero to do with dedication or discipline.
And for the record, the C#/.Net development language and environment was created primarily to address the issues I've mentioned (MS was getting tired of being ridiculed for all the bugs and holes that were being discovered on nearly a daily basis), developer speed/efficiency is just a side benefit.
|
|
2009-11-09
, 14:31
|
|
Posts: 1,217 |
Thanked: 446 times |
Joined on Oct 2009
@ Bedfordshire, UK
|
#25
|
Originally Posted by texaslabrat
But all of these are for more powerful systems - the thread was for Mobile devices I believe!
Well, same here..I've worked in just about everything under the sun at one time or another...and the thing that I brought away from that is that leaving memory management and garbage collection to the developers is a bugzilla event waiting to happen.
And yes, there are some problems with even JIT languages (guess what language the JIT compiler was written in LOL), but to fix those is a swapping of the run time rather than re-writing every application ever distributed.
And yes, it is about being "perfect" because no amount of engineering discipline can overcome the propensity to commit typos after 10's of thousands of lines of code. That's human nature...and has zero to do with dedication or discipline.
And for the record, the C#/.Net development language and environment was created primarily to address the issues I've mentioned (MS was getting tired of being ridiculed for all the bugs and holes that were being discovered on nearly a daily basis), developer speed/efficiency is just a side benefit.
As for engineering discipline - that's what QA and testing are for.
As for the reason for the .NET environment development I'd love to see the citation for that. My information from inside MS was that it was they needed to move away from legacy support as well as stability. The C# bit was due to being unable to continue with J++ which even resulted in no J++ project staff being able to work on the C# project to avoid litigation expsoure.
JIT's are to reduce developer time - in original delivery or debug time. They are an overhead in themselves which may be acceptable in a larger project on a more powerful platform but they do hit mobile. OOP and OOD was designed to reduce the thousands of lines of code issue though I have seen some interesting impimentations of this that write huge classes.
Anyhow - all of this is getting way off the point....
Maybe we should just agree to disagree on this - at least debate keeps the community lively and all of us on our toes!
|
|
2009-11-09
, 18:45
|
|
Posts: 607 |
Thanked: 450 times |
Joined on Sep 2009
@ Washington, DC
|
#26
|
Originally Posted by fpp
Well I'm one of the two (and it's FORTRAN you young whippersnapper). Actually, I would note that there is a binding for a real programming language, Pascal (which was based on ALGOL) so there's hope for us dinosaurs yet.
Yes, Den, 'fraid so... you and those two other guys doing COBOL and FORTAN should group together :-)
| The Following User Says Thank You to DaveP1 For This Useful Post: | ||
 |
|
2009-11-09
, 20:08
|
|
Posts: 2,853 |
Thanked: 968 times |
Joined on Nov 2005
|
#27
|
Originally Posted by DaveP1
Oooops, sorry for the typo -- I'll whip out my time machine and go correct that (thus turning your quote into a space-time threatening paradox). It definitely is a typo BTW, as I actually ran FORTRAN programs on punch cards myself a while ago, so there :-)
Well I'm one of the two (and it's FORTRAN you young whippersnapper). Actually, I would note that there is a binding for a real programming language, Pascal (which was based on ALGOL) so there's hope for us dinosaurs yet.
__________________
maemo blog
maemo blog
|
|
2009-11-09
, 20:15
|
|
Posts: 1,217 |
Thanked: 446 times |
Joined on Oct 2009
@ Bedfordshire, UK
|
#28
|
Originally Posted by DaveP1
Eek - Formula Translation - aaagh. Ooh the nightmares of coding in that. Bloody fast and very efficient but i still bear the trauma from cross coding from DEC to PRIME! LOL
Well I'm one of the two (and it's FORTRAN you young whippersnapper). Actually, I would note that there is a binding for a real programming language, Pascal (which was based on ALGOL) so there's hope for us dinosaurs yet.
Pascal could be interesting though if you're an ALGOL guy then C/C++ or Java and Python shouldn't be too far away from where you feel comfy. C might be the closest though.
|
|
2009-11-09
, 20:17
|
|
Posts: 1,217 |
Thanked: 446 times |
Joined on Oct 2009
@ Bedfordshire, UK
|
#29
|
Originally Posted by fpp
You know we could really start a fright on here and start a brainstorm request for FORTRAN-77 bindings into QT ! LOL
Oooops, sorry for the typo -- I'll whip out my time machine and go correct that (thus turning your quote into a space-time threatening paradox). It definitely is a typo BTW, as I actually ran FORTRAN programs on punch cards myself a while ago, so there :-)
 |
|
2009-11-09
, 20:26
|
|
Posts: 332 |
Thanked: 76 times |
Joined on Oct 2007
@ St. Augustine, Trinidad and Tobago
|
#30
|
Sorry for any ignorance, but isn't fortran now part of gcc, so maybe it already exists for the Nxx0 tablets?
__________________
- N900
- N800
- LD-3W
- two magic OTG USB adapters
- crossed fingers
Plus, the problem with books written by programmers is that they are for programmers, they assume too much knowledge even when they state 'for beginners'
I plan on cutting my teeth on the web tutorials for a couple of months and then I will be in a state where I might actually understand some of the stuff I will read in that book, if I don't, then I will be posting back here...
Hi! I'm Martin, a Maemo Greeter!
Useful links for newcomers: New members say hello, New users start here, Community subforum , Beginners'wiki page, Maemo5 101, Frequently Asked Questions (FAQ)
If I can help with anything else, just ask!