Groups > comp.lang.python > #90304 > unrolled thread

Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses BOTH? Good idea?

Started by	Chris Seberino <cseberino@gmail.com>
First post	2015-05-10 13:43 -0700
Last post	2015-05-11 09:29 -0700
Articles	20 on this page of 68 — 17 participants

Back to article view | Back to comp.lang.python

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

#90471

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-12 10:35 -0700
Message-ID	<f84f7383-8fae-4b2d-b5d2-70285a46e584@googlegroups.com>
In reply to	#90454

On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote:
> On Tuesday, May 12, 2015 at 4:16:31 AM UTC-5, Rustom Mody wrote:
> > On Tuesday, May 12, 2015 at 12:27:44 PM UTC+5:30, Chris Angelico wrote:
> > > On Tue, May 12, 2015 at 4:42 PM, Rustom Mody  wrote:
> > > > And related to that (and one reason a pure functional language is good for
> > > > pedagogy): NO PRINT statement
> > > > It may seem trivial but beginning students have a real hard writing clean
> > > > structured code.  Tabooing prints helps get there faster
> > > > And working in the interpreter makes a print-taboo a viable option
> > > 
> > > I firmly disagree.
> > 
> > Yes we know that!
> > 
> > As it happens you also disagree with ACM's latest CS curriculum:
> 
> I/O is an essential part of computing in the West.  (I'll leave Symbolics out of of that category.)  It started with switches and lights, so what kind of bullshit is saying that you should get rid of PRINT?  ACM must have gotten confused or steamrolled by one of its members.

In the West? WEST??
Did I hear that right?

My profound genuflections to the Mark-modified Michaelson-Morley result.

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

#90476

From	Mark Lawrence <breamoreboy@yahoo.co.uk>
Date	2015-05-12 19:22 +0100
Message-ID	<mailman.408.1431454962.12865.python-list@python.org>
In reply to	#90471

On 12/05/2015 18:35, Rustom Mody wrote:
> On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote:
>>
>> I/O is an essential part of computing in the West.  (I'll leave Symbolics out of of that category.)  It started with switches and lights, so what kind of bullshit is saying that you should get rid of PRINT?  ACM must have gotten confused or steamrolled by one of its members.
>
> In the West? WEST??
> Did I hear that right?
>

I prefer this[1]

<quote>
Each object has to figure out how it will receive things from outside
of it.  Things it can't handle (a string sent to an int) just have to
be dropped to some other space, much like stderr does within the O.S.

There are probably many other very interesting examples, but the key
idea I'm working on (as noted in other messages), is a sort-of
universal language for the internet, a WebOS to be applied to a
universal data model.
</quote>

I'd guess that the concept is in the same boat as Python 2.8 or 
RickedPython, but I suspect that these two have far more chance of 
making it into the real world than "a sort-of universal language for the 
internet, a WebOS to be applied to a universal data model"

[1]https://mail.python.org/pipermail/python-ideas/2013-March/019979.html
-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#90519

From	zipher <dreamingforward@gmail.com>
Date	2015-05-12 20:08 -0700
Message-ID	<3aa9c854-4a46-47b8-9742-5f3744557f6c@googlegroups.com>
In reply to	#90476

On Tuesday, May 12, 2015 at 1:22:55 PM UTC-5, Mark Lawrence wrote:
> On 12/05/2015 18:35, Rustom Mody wrote:
> > On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote:
> >>
> >> I/O is an essential part of computing in the West.  (I'll leave Symbolics out of of that category.)  It started with switches and lights, so what kind of bullshit is saying that you should get rid of PRINT?  ACM must have gotten confused or steamrolled by one of its members.
> >
> > In the West? WEST??
> > Did I hear that right?
> >
> 
> I prefer this[1]
> [1]https://mail.python.org/pipermail/python-ideas/2013-March/019979.html
> Mark Lawrence

I was trying to differentiate models of computing.  Perhaps you don't know the concept.  I'll refer you to http://c2.com/cgi/wiki?ModelsOfComputation.  One might think that they ALL originated from Western Civ, but not quite.

Yes, I was sounding little too enthusiastic in that post.

Mark

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

#90461

From	Mark Lawrence <breamoreboy@yahoo.co.uk>
Date	2015-05-12 17:04 +0100
Message-ID	<mailman.399.1431446652.12865.python-list@python.org>
In reply to	#90435

On 12/05/2015 07:42, Rustom Mody wrote:
>
> And related to that (and one reason a pure functional language is good for
> pedagogy): NO PRINT statement
> It may seem trivial but beginning students have a real hard writing clean
> structured code.  Tabooing prints helps get there faster
> And working in the interpreter makes a print-taboo a viable option
>

If students can't be taught to distinguish print from other parts of the 
language they should get themselves onto a course teaching semi-skilled 
light bulb fitting.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#90453

From	zipher <dreamingforward@gmail.com>
Date	2015-05-12 08:11 -0700
Message-ID	<569169cf-d232-48c0-bd49-91090e9c0ddb@googlegroups.com>
In reply to	#90429

On Monday, May 11, 2015 at 9:04:24 PM UTC-5, Steven D'Aprano wrote:
> On Tue, 12 May 2015 05:01 am, beliavsky@aol.com wrote:
> 
> > Yale has taken the unusual step of outsourcing its introductory CS class
> > to Harvard, which uses C as the main language in its CS50 class.
> 
> And another generation of new programmers will be irreversibly damaged by
> exposure to C...

Come on, C is perfect for computer engineering students.  For CS students, it's of mixed value.

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

#90467

From	Rob Gaddi <rgaddi@technologyhighland.invalid>
Date	2015-05-12 17:03 +0000
Message-ID	<mitbph$2sq$3@dont-email.me>
In reply to	#90453

On Tue, 12 May 2015 08:11:25 -0700, zipher wrote:

> On Monday, May 11, 2015 at 9:04:24 PM UTC-5, Steven D'Aprano wrote:
>> On Tue, 12 May 2015 05:01 am, beliavsky@aol.com wrote:
>> 
>> > Yale has taken the unusual step of outsourcing its introductory CS
>> > class to Harvard, which uses C as the main language in its CS50
>> > class.
>> 
>> And another generation of new programmers will be irreversibly damaged
>> by exposure to C...
> 
> Come on, C is perfect for computer engineering students.  For CS
> students, it's of mixed value.

And that's how you train CS students to write inefficient code that takes 
orders of magnitude longer to run than it should.

Is that a true array or a linked list?  "It's a high level language, 
that's just an implementation detail." Yes, but it's an implementation 
detail that determines whether even the simple act of looking up element 
n is O(1) or O(n).

C teaches you the language of the computer.  Understanding it allows you 
to grasp what your high-level code is actually doing, and why and when a 
list (array) is more efficient than a dict (hashtable).  Because you've 
written a dynamically resizing list, and learned the perils of having to 
realloc() as the size grows.  And you've written a hashtable, and 
understand the expense of the hashing function, and the tradeoffs between 
wasted memory and having to wade at O(n) pace through a linked list of 
collision candidates.

A firm grasp of C will make you a better programmer in any language, even 
if you haven't written a line of it in 20 years.  It's the ability to 
read a map.  A lack of C is the person blindly following their GPS and 
hoping for the best.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#90469

From	Chris Angelico <rosuav@gmail.com>
Date	2015-05-13 03:15 +1000
Message-ID	<mailman.405.1431450952.12865.python-list@python.org>
In reply to	#90467

On Wed, May 13, 2015 at 3:03 AM, Rob Gaddi
<rgaddi@technologyhighland.invalid> wrote:
> A firm grasp of C will make you a better programmer in any language, even
> if you haven't written a line of it in 20 years.  It's the ability to
> read a map.  A lack of C is the person blindly following their GPS and
> hoping for the best.

That's as may be, but I would still not recommend it as a first
language. It's possible to explain algorithmic complexity with a high
level language; Python's data types generally have predictable costs
associated with them, although a lot of them aren't actually language
guarantees (I could imagine a Python implementation using an O(log n)
tree instead of an amortized O(1) hash table for its dict, if other
tradeoffs make it worthwhile); at any rate, you can always just
construct your own fundamental data structures if you want to teach
what a linked list is good for, or what a splay tree can do for you. C
knowledge is good, but first get to know the broader art of
programming, and then get to know C. Learning low-level languages too
soon will end up binding your mind to a particular CPU architecture.
That happened to me in a big way; I got to thinking about everything
in terms of how an 80x86 CPU would deal with it, without any
comprehension of some of the modern aspects of low-level programming
like pipeline management and cache locality. It was quite the
eye-opener when I started hand-optimizing my C compiler's output on a
more modern chip, and found that my improvements... uhh, added about
50% to the run time. That's when I stopped doing any assembly language
work, and just let the compiler do its magic :)

ChrisA

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

#90483

From	Marko Rauhamaa <marko@pacujo.net>
Date	2015-05-12 22:52 +0300
Message-ID	<878ucty3nv.fsf@elektro.pacujo.net>
In reply to	#90469

Chris Angelico <rosuav@gmail.com>:

> That's as may be, but I would still not recommend [C] as a first
> language.

I think the field can be approached from many angles successfully. And
any approach will fail many students.

The nice thing about C is that your feet are firmly on the ground.
There's little magic. You can then abstract your concrete knowledge of C
to higher-level concepts.

In fact, going the other way could be harder. I'm thinking the lofty
abstractions like objects will remain sort of mysteries without an
experience with a low-level language.

That's why first-graders are not given education in abstract algebra or
category theory. They are first taught elementary arithmetics. The lofty
concepts are abstracted from the low-level concepts and not the other
way around. (I had a feeling in high-school that math was easy. In the
university, I had the opposite experience: I hadn't understood a thing
in high-school. However, the elementary "wrong" knowledge was a stepping
stone to the "correct" understanding.)


Marko

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

#90470

From	Chris Angelico <rosuav@gmail.com>
Date	2015-05-13 03:26 +1000
Message-ID	<mailman.406.1431451597.12865.python-list@python.org>
In reply to	#90467

On Wed, May 13, 2015 at 3:15 AM, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
>>Is that a true array or a linked list?  "It's a high level language,
>>that's just an implementation detail." Yes, but it's an implementation
>>detail that determines whether even the simple act of looking up element
>>n is O(1) or O(n).
>
>   The complexity is given in the documentation of high-level languages.
>
>   For example, from the documentation of the Java standard library:
>
>       »This implementation provides constant-time performance
>       for the basic operations (get and put),« (java.util.HashMap)
>
>   C++:
>
>       Section 23.2.1 specifies the complexity, such as »compile time«,
>       »constant«, »linear« for container operations.
>
>   But the abstraction mechanisms (templates, polymorphism)
>   often allow one to change the implementation quite easily.

It isn't always given in the docs. Sometimes it's not even a promise;
back when MicroPython was debating the implementation of Unicode
strings, there was a lengthy discussion on python-dev about whether
it's okay for string subscripting to be O(n) instead of O(1), and the
final decision was that yes, that's an implementation detail. (UTF-8
internal string representation, so iterating over a string would still
yield characters in overall O(n), but iterating up to the string's
length and subscripting for each character would become O(n*n) on
uPy.)

ChrisA

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

#90511 — uPy Unicode [was Re: Instead of deciding between Python or Lisp blah blah blah]

From	Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Date	2015-05-13 11:23 +1000
Subject	uPy Unicode [was Re: Instead of deciding between Python or Lisp blah blah blah]
Message-ID	<5552a774$0$12993$c3e8da3$5496439d@news.astraweb.com>
In reply to	#90470

On Wed, 13 May 2015 03:26 am, Chris Angelico wrote:

> back when MicroPython was debating the implementation of Unicode
> strings, there was a lengthy discussion on python-dev about whether
> it's okay for string subscripting to be O(n) instead of O(1), and the
> final decision was that yes, that's an implementation detail. (UTF-8
> internal string representation, so iterating over a string would still
> yield characters in overall O(n), but iterating up to the string's
> length and subscripting for each character would become O(n*n) on
> uPy.)

o_O

Got a link to that? I must have missed it.


-- 
Steven

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

#90527 — Re: uPy Unicode [was Re: Instead of deciding between Python or Lisp blah blah blah]

From	Chris Angelico <rosuav@gmail.com>
Date	2015-05-13 15:13 +1000
Subject	Re: uPy Unicode [was Re: Instead of deciding between Python or Lisp blah blah blah]
Message-ID	<mailman.430.1431494021.12865.python-list@python.org>
In reply to	#90511

On Wed, May 13, 2015 at 11:23 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 13 May 2015 03:26 am, Chris Angelico wrote:
>
>> back when MicroPython was debating the implementation of Unicode
>> strings, there was a lengthy discussion on python-dev about whether
>> it's okay for string subscripting to be O(n) instead of O(1), and the
>> final decision was that yes, that's an implementation detail. (UTF-8
>> internal string representation, so iterating over a string would still
>> yield characters in overall O(n), but iterating up to the string's
>> length and subscripting for each character would become O(n*n) on
>> uPy.)
>
> o_O
>
> Got a link to that? I must have missed it.

Linking to python-dev is a bit fiddly and/or unstable due to URL
changes, plus the discussion there was pretty long and rambly.
Probably the best I can do is point you to the tracker issue where I
opened the original question:

https://github.com/micropython/micropython/issues/657

(The biggest issue was that uPy was, at the time, fundamentally
incompatible with Python's stipulated semantics - imagine all the
problems of a narrow build of CPython <3.3, only more frequent because
it's actually UTF-8.)

It was finally decided, I think, that Python-the-language didn't
actually mandate O(1) indexing, meaning that a microcontroller (on
which strings aren't going to be gigantic anyway) is welcome to use a
UTF-8 internal representation, with "Hello, world"[4] required to scan
across and count non-continuation bytes to find the right character.
Whether or not uPy actually ended up accepting the requirements of
proper Unicode support I don't know, as I'm no longer involved with
the project.

ChrisA

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

#90472

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-12 10:57 -0700
Message-ID	<d67fa8aa-6ea8-4d22-b8bf-69d6a23392ed@googlegroups.com>
In reply to	#90467

On Tuesday, May 12, 2015 at 10:45:39 PM UTC+5:30, Stefan Ram wrote:
> Rob Gaddi writes:
> >Is that a true array or a linked list?  "It's a high level language, 
> >that's just an implementation detail." Yes, but it's an implementation 
> >detail that determines whether even the simple act of looking up element 
> >n is O(1) or O(n).
> 
>   The complexity is given in the documentation of high-level languages.
> 
>   For example, from the documentation of the Java standard library:
> 
>       »This implementation provides constant-time performance
>       for the basic operations (get and put),« (java.util.HashMap)
> 
>   C++:
> 
>       Section 23.2.1 specifies the complexity, such as »compile time«,
>       »constant«, »linear« for container operations.
> 
>   But the abstraction mechanisms (templates, polymorphism)
>   often allow one to change the implementation quite easily.

This is regarded in some circles as one of the big open problems in CS
https://existentialtype.wordpress.com/2014/09/28/structure-and-efficiency-of-computer-programs/
[and the position paper therein]
viz how to integrate the elegance of high-level languages
with the precision of complexity analysis of machine language

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

#90499

From	zipher <dreamingforward@gmail.com>
Date	2015-05-12 15:00 -0700
Message-ID	<1fdbee0a-b425-44ff-b706-b6b407358bf1@googlegroups.com>
In reply to	#90472

On Tuesday, May 12, 2015 at 12:57:48 PM UTC-5, Rustom Mody wrote:
> On Tuesday, May 12, 2015 at 10:45:39 PM UTC+5:30, Stefan Ram wrote:
> > Rob Gaddi writes:
> > >Is that a true array or a linked list?  "It's a high level language, 
> > >that's just an implementation detail." Yes, but it's an implementation 
> > >detail that determines whether even the simple act of looking up element 
> > >n is O(1) or O(n).
> > 
> >   The complexity is given in the documentation of high-level languages.
> > 
> >   For example, from the documentation of the Java standard library:
> > 
> >       »This implementation provides constant-time performance
> >       for the basic operations (get and put),« (java.util.HashMap)
> > 
> >   C++:
> > 
> >       Section 23.2.1 specifies the complexity, such as »compile time«,
> >       »constant«, »linear« for container operations.
> > 
> >   But the abstraction mechanisms (templates, polymorphism)
> >   often allow one to change the implementation quite easily.
> 
> This is regarded in some circles as one of the big open problems in CS
> https://existentialtype.wordpress.com/2014/09/28/structure-and-efficiency-of-computer-programs/
> [and the position paper therein]
> viz how to integrate the elegance of high-level languages
> with the precision of complexity analysis of machine language

The answer is you don't.  You *don't* because you can't.  And you *can't* because you don't know what you want to do yet.  

That is why you have very high-level languages that allow you to rapidly prototype ideas, test them, and then, depending all the other constraints, move them to lower-level language implementations.

So don't try it.  Everyone gets it wrong and now we have a plethora of languages which all do the same thing, without really knowing what they want as an overarching design or purpose.

Mark

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

#90501

From	Marko Rauhamaa <marko@pacujo.net>
Date	2015-05-13 01:24 +0300
Message-ID	<87y4ktwi20.fsf@elektro.pacujo.net>
In reply to	#90499

zipher <dreamingforward@gmail.com>:

> That is why you have very high-level languages that allow you to
> rapidly prototype ideas, test them, and then, depending all the other
> constraints, move them to lower-level language implementations.

Finally an argument to tackle. That rapid prototyping role is often
mentioned as a strong point of high-level languages. However, I can't
remember personally doing that. Rather, you want to use the right
programming language for any given role.

Bash has really concise idioms as long as you stay within its comfort
zone. When you need finer-grained control, a bash program quickly
becomes very tacky. I have had to rewrite bash components in Python for
that reason. What is gained is clarity of expression at the cost of 2 to
5 times more code. And where performance is an issue, C does the job
nicely.

The end result is a system with bash, Python and C components that
interact through the regular linux IPC mechanisms.


Marko

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

#90520

From	zipher <dreamingforward@gmail.com>
Date	2015-05-12 20:11 -0700
Message-ID	<20f6a95e-85d7-4b59-8b4d-3d2ae2626f2c@googlegroups.com>
In reply to	#90501

On Tuesday, May 12, 2015 at 5:24:34 PM UTC-5, Marko Rauhamaa wrote:
> zipher <dreamingforward@gmail.com>:
> 
> > That is why you have very high-level languages that allow you to
> > rapidly prototype ideas, test them, and then, depending all the other
> > constraints, move them to lower-level language implementations.
> 
> Finally an argument to tackle. That rapid prototyping role is often
> mentioned as a strong point of high-level languages. However, I can't
> remember personally doing that. Rather, you want to use the right
> programming language for any given role.

I know.  That's because most people have fallen off the path (http://c2.com/cgi/wiki?OneTruePath).  You haven't done it because either others have done it for you (NumPy) or you simply aren't perfecting anything that needs to scale; i.e. you don't really need to minimize memory or CPU consumption because you're working with toy problems relative to the power of most hardware these days.

Mark

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

#90524

From	Ian Kelly <ian.g.kelly@gmail.com>
Date	2015-05-12 21:46 -0600
Message-ID	<mailman.427.1431488855.12865.python-list@python.org>
In reply to	#90520

On Tue, May 12, 2015 at 9:11 PM, zipher <dreamingforward@gmail.com> wrote:
> I know.  That's because most people have fallen off the path (http://c2.com/cgi/wiki?OneTruePath).

You wrote that, didn't you? I recognize that combination of delusional
narcissism and curious obsession with Turing machines.

> You haven't done it because either others have done it for you (NumPy) or you simply aren't perfecting anything that needs to scale; i.e. you don't really need to minimize memory or CPU consumption because you're working with toy problems relative to the power of most hardware these days.

There is such a thing as over-optimization. Given unlimited programmer
time, sure, everything might be made to run using the minimum possible
time and space. Nobody has unlimited time, though. The job of the
programmer is to get the program to run "fast enough" for the needs of
the application. Getting it to run faster than it needs to is
generally a waste of the programmer's time that could be spent on more
valuable tasks.

Of course, I say this as somebody who works on a highly scaled
user-facing application that will never be "fast enough". :-)

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

#90532

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-12 23:36 -0700
Message-ID	<b3b151c8-54a0-423b-8ddc-4679ba50e766@googlegroups.com>
In reply to	#90524

On Wednesday, May 13, 2015 at 9:17:48 AM UTC+5:30, Ian wrote:
> On Tue, May 12, 2015 at 9:11 PM, zipher  wrote:
> > I know.  That's because most people have fallen off the path (http://c2.com/cgi/wiki?OneTruePath).
> 
> You wrote that, didn't you? I recognize that combination of delusional
> narcissism and curious obsession with Turing machines.

Interestingly saw this (CACM) the other day:

http://www.tomandmaria.com/Tom/Writing/CACMActuallyTuringDidNotInventTheComputer.pdf

non-delusional and in the opposite direction:

Turing's is a paper on mathematical logic. It describes a
thought experiment, like Schrödinger's famous 1935 description of
a trapped cat shifting between life and death in response to the
behavior of a single atom. Schrödinger was not trying to advance
the state of the art of feline euthanasia. Neither was Turing
proposing the construction of a new kind of calculating machine.
As the title of his paper suggested, Turing designed his
ingenious imaginary machines to address a question about the
fundamental limits of mathematical proof. They were structured
for simplicity, and had little in common 
with the approaches taken by people 
designing actual machines. 

Von Neumann's report said nothing explicitly about mathematical
logic. It described the architecture of an actual planned
computer and the technologies by which it could be realized, and
was written to guide the team that had already won a contract to
develop the EDVAC. Von Neumann does abstract away from details of
the hardware, both to focus instead on what we would now call
"architecture" and because the computer projects under way at the
Moore School were still classified in 1945. His letters from that
period are full of discussion of engineering details, such as
sketches of particular vacuum tube models and their performance
characteristic

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

#90558

From	zipher <dreamingforward@gmail.com>
Date	2015-05-13 07:49 -0700
Message-ID	<eb476e26-bd1f-43e6-aa7f-db4bcff280ba@googlegroups.com>
In reply to	#90524

On Tuesday, May 12, 2015 at 10:47:48 PM UTC-5, Ian wrote:
> On Tue, May 12, 2015 at 9:11 PM, zipher <dreamingforward@gmail.com> wrote:
> > I know.  That's because most people have fallen off the path (http://c2.com/cgi/wiki?OneTruePath).
> 
> You wrote that, didn't you? I recognize that combination of delusional
> narcissism and curious obsession with Turing machines.

Damn straight.  But to call the reference to Turing machines delusional, means you've already been captured by the first enemy on the Path.  (cf. Javascript!)

> > You haven't done it because either others have done it for you (NumPy) or you simply aren't perfecting anything that needs to scale; i.e. you don't really need to minimize memory or CPU consumption because you're working with toy problems relative to the power of most hardware these days.
> 
> There is such a thing as over-optimization. Given unlimited programmer
> time, sure, everything might be made to run using the minimum possible
> time and space.

You don't need to teach me these basics.  If you had read the document, you would have seen that I already had assimilated the lessons of [Master] Jon Bentley.  I know about over-optimization, however, if you had followed my other posts, you would also know that I'm attempting something that will require some interest in the underlying hardware at some point.  Or, perhaps let's say, it's just my personal (unique?) preference not to create bloatware.

mark

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

#90573

From	Grant Edwards <invalid@invalid.invalid>
Date	2015-05-13 17:56 +0000
Message-ID	<mj037p$6tp$1@reader1.panix.com>
In reply to	#90501

On 2015-05-12, Marko Rauhamaa <marko@pacujo.net> wrote:
> zipher <dreamingforward@gmail.com>:
>
>> That is why you have very high-level languages that allow you to
>> rapidly prototype ideas, test them, and then, depending all the other
>> constraints, move them to lower-level language implementations.
>
> Finally an argument to tackle. That rapid prototyping role is often
> mentioned as a strong point of high-level languages. However, I can't
> remember personally doing that.

I've done that on several occasions: develop and debug an algorithm or
protocol using Python, then re-write it in C once I'm happy with the
way it works.  Those instances are not for desktop use, though.  They
final app has to run on an embedded system that has zero chance of
ever supporting Python.

-- 
Grant Edwards               grant.b.edwards        Yow! YOU PICKED KARL
                                  at               MALDEN'S NOSE!!
                              gmail.com

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

#90515

From	Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Date	2015-05-13 12:30 +1000
Message-ID	<5552b74e$0$12985$c3e8da3$5496439d@news.astraweb.com>
In reply to	#90499

On Wed, 13 May 2015 08:00 am, zipher wrote:

> Everyone gets it wrong and now we have a plethora of languages which all
> do the same thing, without really knowing what they want as an overarching
> design or purpose.

Why must a language be designed with some "overarching design or purpose"?

Why can't a language be designed with a *practical and concrete* need in
mind? As far as I know, only one language designed from theoretical first
principles has had any measure of mainstream success, Lisp, and that was
probably because there weren't that many decent alternatives at the time.

"I want to do numerical calculations" lead to Fortran.

"I want to control telescopes" lead to Forth.

"I want to teach beginners programming" lead to BASIC.

"I want to teach beginners good programming" lead to Pascal.

"I want to generate webpages on the fly" lead to PHP.

"I want to write interactive fiction and text-based games" lead to Inform.

And so forth.

-- 
Steven

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

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

csiph-web

Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?

Contents

#90471

#90476

#90519

#90461

#90453

#90467

#90469

#90483

#90470

#90511 — uPy Unicode [was Re: Instead of deciding between Python or Lisp blah blah blah]

#90527 — Re: uPy Unicode [was Re: Instead of deciding between Python or Lisp blah blah blah]

#90472

#90499

#90501

#90520

#90524

#90532

#90558

#90573

#90515

Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses BOTH? Good idea?