On Tuesday, October 13, 2015 at 9:40:56 AM UTC-4, Steven D'Aprano wrote:
> On Tue, 13 Oct 2015 06:55 pm, Todd wrote:
>
> > On Oct 13, 2015 2:11 AM, "Steven D'Aprano" <...> wrote:
>
> >> Consider the following piece of code:
> >>
> >> def addone(x):
> >> return x + 1
> >>
> >>
> >> The human p
On Tuesday, October 13, 2015 at 2:52:32 PM UTC-4, Sibylle Koczian wrote:
> Am 13.10.2015 um 00:10 schrieb Ben Finney:
> > Sibylle Koczian <> writes:
> >
> >> Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:
> >>> Auto-complete is a fine and useful tool. But if you are crippled as a
> >>> programmer
m wrote:
W dniu 13.10.2015 o 03:35, Michael Torrie pisze:
Well in Java code for one. No wonder they require auto-completion.
Java class-based namespaces must be a nightmare to work with.
IMHO mainly because their naming convention. They just love typing long
names.
The biggest verbosity p
Bartc wrote:
I've surprised Basic needs it. The last time I looked, $A was a string,
%B an integer, and C a number.
A$ and B%, actually.
Although if you didn't like the type suffixes, you
could say DEFINT I-N and pretend you were writing
Fortran code. :-)
--
Greg
--
https://mail.python.org/ma
Ben Finney wrote:
* The overwhelming majority of .NET and Java programmers would feel
crippled without auto-complete. (assertion made by Sibylle)
An obvious resolution is to conclude that the
overwhelming majority of Java and .NET programmers cannot claim to
understand those technologies.
A
Am 13.10.2015 um 00:10 schrieb Ben Finney:
Sibylle Koczian writes:
Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:
Auto-complete is a fine and useful tool. But if you are crippled as a
programmer without it, well, then you can hardly claim to understand the
language or framework you are progr
On Tue, 13 Oct 2015 06:55 pm, Todd wrote:
> On Oct 13, 2015 2:11 AM, "Steven D'Aprano" wrote:
>> Consider the following piece of code:
>>
>> def addone(x):
>> return x + 1
>>
>>
>> The human programmer reading that can trivially infer that x must be a
>> number (or at least something which s
In a message of Tue, 13 Oct 2015 13:31:56 +0100, Bartc writes:
>On 13/10/2015 11:42, Marko Rauhamaa wrote:
>
>> A few years back I programmed in Java. I literally had to write (or
>> generate) 2,000 lines of code to satisfy the structural requirements
>> (interfaces, method stubs, javadocs, ...) be
On 13/10/2015 11:42, Marko Rauhamaa wrote:
A few years back I programmed in Java. I literally had to write (or
generate) 2,000 lines of code to satisfy the structural requirements
(interfaces, method stubs, javadocs, ...) before the code actually did
anything.
And this is the recommended langu
Laura Creighton :
> When Design Patterns were new, the 2 of the first books to come out
> were 'Design Patterns'[1995] which was C++ focused, and the 'Design
> Patterns Smalltalk Companion'[1998]. If you read the two of them, side
> by side (as DPSTC asks you to) you will be struct by how little o
In a message of Mon, 12 Oct 2015 19:35:57 -0600, Michael Torrie writes:
>On 10/12/2015 06:07 PM, Steven D'Aprano wrote:
>> Where is the "vast amounts of noise" added to the code?
>
>Well in Java code for one. No wonder they require auto-completion.
>Java class-based namespaces must be a nightmare
W dniu 13.10.2015 o 03:35, Michael Torrie pisze:
> On 10/12/2015 06:07 PM, Steven D'Aprano wrote:
>> > Where is the "vast amounts of noise" added to the code?
> Well in Java code for one. No wonder they require auto-completion.
> Java class-based namespaces must be a nightmare to work with.
IMHO
On Oct 13, 2015 2:11 AM, "Steven D'Aprano" wrote:
>
> On Tue, 13 Oct 2015 04:20 am, Marko Rauhamaa wrote:
>
> > As for managing complexity, many people believe static typing is a
> > crucial tool. I disagree. Static typing adds vast amounts of noise to
> > the code.
>
> Only if you are stuck in th
On 10/12/2015 06:07 PM, Steven D'Aprano wrote:
> Where is the "vast amounts of noise" added to the code?
Well in Java code for one. No wonder they require auto-completion.
Java class-based namespaces must be a nightmare to work with. That and
all the over-use of design patterns that Java librari
On 13/10/2015 01:07, Steven D'Aprano wrote:
On Tue, 13 Oct 2015 04:20 am, Marko Rauhamaa wrote:
As for managing complexity, many people believe static typing is a
crucial tool. I disagree. Static typing adds vast amounts of noise to
the code.
Only if you are stuck in the 1970s. And even then,
On Tue, 13 Oct 2015 04:20 am, Marko Rauhamaa wrote:
> As for managing complexity, many people believe static typing is a
> crucial tool. I disagree. Static typing adds vast amounts of noise to
> the code.
Only if you are stuck in the 1970s. And even then, it is not always noise,
type declarations
Sibylle Koczian writes:
> Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:
> > Auto-complete is a fine and useful tool. But if you are crippled as a
> > programmer without it, well, then you can hardly claim to understand the
> > language or framework you are programming in if you cannot use it wi
On 10/12/2015 12:08 PM, Michael Torrie wrote:
Also many Python editing environments do support basic completion.
However completion is actually very difficult to implement in a static
manner because Python is so dynamic. I can import any standard library
module and rename it as needed. Since s
On Mon, Oct 12, 2015 at 1:50 PM, Bartc wrote:
> On 12/10/2015 18:20, Marko Rauhamaa wrote:
>
>> Bartc :
>>
>> (Example, calling fib(40) on the example below took 90 seconds on
>>> Python 3.4, 11 seconds with PyPy, but only 1.8 seconds running the
>>> equivalent with FreeBasic:
>>>
>>
>> I don't k
On 12/10/2015 18:20, Marko Rauhamaa wrote:
Bartc :
(Example, calling fib(40) on the example below took 90 seconds on
Python 3.4, 11 seconds with PyPy, but only 1.8 seconds running the
equivalent with FreeBasic:
I don't know what you need fibonacci numbers for,
It's a benchmark that gives yo
Bartc :
> (Example, calling fib(40) on the example below took 90 seconds on
> Python 3.4, 11 seconds with PyPy, but only 1.8 seconds running the
> equivalent with FreeBasic:
I don't know what you need fibonacci numbers for, but speed is not the
essence of most programming tasks. Rather, the key i
On 12/10/2015 16:47, Michael Torrie wrote:
On 10/12/2015 07:30 AM, Bartc wrote:
On 12/10/2015 03:45, Michael Torrie wrote:
C++ introduced it a while ago (C++11), and D has had it from the
beginning. Even lowly FreeBasic has it.
[I'm] surprised Basic needs it. The last time I looked, $A was
On Mon, Oct 12, 2015 at 2:47 AM, John Michael Lafayette
wrote:
> Now that Python has static type checking and support for IDE auto-complete
> (PEP 484?), I beg you to please use it. In your standard library, in your
> production code, in everywhere. I cannot type without auto-complete.
*Decent* P
Il giorno lunedì 12 ottobre 2015 10:51:50 UTC+2, John Michael Lafayette ha
scritto:
> Now that Python has static type checking and support for IDE auto-complete
> (PEP 484?), I beg you to please use it. In your standard library, in your
> production code, in everywhere. I cannot type without aut
On 10/12/2015 02:47 AM, John Michael Lafayette wrote:
> Now that Python has static type checking and support for IDE auto-complete
> (PEP 484?), I beg you to please use it. In your standard library, in your
> production code, in everywhere. I cannot type without auto-complete.
>
> I know that soun
On 10/12/2015 07:30 AM, Bartc wrote:
> On 12/10/2015 03:45, Michael Torrie wrote:
>> On 10/11/2015 06:34 PM, Steven D'Aprano wrote:
>>> That's called type inference, and there's nothing innovative about Swift to
>>> include that as a feature. Type inference is *old*. The theory behind type
>>> infe
Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:
Auto-complete is a fine and useful tool. But if you are crippled as a
programmer without it, well, then you can hardly claim to understand the
language or framework you are programming in if you cannot use it without
an IDE doing half the work for y
On 12/10/2015 03:45, Michael Torrie wrote:
On 10/11/2015 06:34 PM, Steven D'Aprano wrote:
That's called type inference, and there's nothing innovative about Swift to
include that as a feature. Type inference is *old*. The theory behind type
inference goes back to 1958, and languages such as ML a
On Mon, 12 Oct 2015 07:47 pm, John Michael Lafayette wrote:
> Now that Python has static type checking
It certainly does not. It appears you have misunderstood the purpose and
meaning of PEP 484.
PEP 484 provides a *standard meaning for function annotations* as
type-hints, which may be useful f
John Michael Lafayette :
> Now that Python has static type checking and support for IDE
> auto-complete (PEP 484?), I beg you to please use it. In your standard
> library, in your production code, in everywhere. I cannot type without
> auto-complete.
>
> I know that sounds ridiculous,
It sure doe
Now that Python has static type checking and support for IDE auto-complete
(PEP 484?), I beg you to please use it. In your standard library, in your
production code, in everywhere. I cannot type without auto-complete.
I know that sounds ridiculous, but I have been coding on a daily basis for
the l
No. Python now has static type checking and IDE auto-complete support. All
you have to do is put the type name in the function declaration.
On Oct 11, 2015 3:45 PM, "Matt Wheeler" wrote:
> On 9 October 2015 at 17:26, John Michael Lafayette
> wrote:
> > I would like Python to have a strong typing
On 10/11/2015 06:34 PM, Steven D'Aprano wrote:
> That's called type inference, and there's nothing innovative about Swift to
> include that as a feature. Type inference is *old*. The theory behind type
> inference goes back to 1958, and languages such as ML and OCaml have
> included it for decades,
On Mon, 12 Oct 2015 10:24 am, Vladimir Ignatov wrote:
> Hi,
>
>> You might like to investigate Boo, which is a .NET-based
>> language with a Python-like syntax:
>
> AFAIK Unity just dropped Boo support from version 5.0 because
> virtually nobody used it.
What's Unity? I've never heard of it. Wh
Hi,
> You might like to investigate Boo, which is a .NET-based
> language with a Python-like syntax:
AFAIK Unity just dropped Boo support from version 5.0 because
virtually nobody used it. Those little known niche languages are
destined to extinct.
Interesting language is Apple's Swift. While it
On 9 October 2015 at 17:26, John Michael Lafayette
wrote:
I would like Python to also be able to also do this:
Animal a = Factory.make("dog")# okay. Dog is Animal.
Dog d = Factory.make("dog") # okay. Dog is Dog.
Cat c = Factory.make("cat") # Runtime error. Dog is
> You can run your code inside a class definition, abuse metaclassing to
replace the namespace with yourown dict and override the __setitem__
function. Then you can implement a var function so it inspect into it's
caller namespace, and inserts the given key into it.
This hack doesn't apply on any s
On 9 October 2015 at 17:26, John Michael Lafayette
wrote:
> I would like Python to have a strong typing feature that can co-exist with
> the current dynamic typing system. Currently Python is like this:
>
> var animal = Factory.make("dog") # okay.
> var dog = Factory.make("dog") # o
On 10/09/2015 10:26 AM, John Michael Lafayette wrote:
> I would like Python to have a strong typing feature that can co-exist with
> the current dynamic typing system. Currently Python is like this:
>
> var animal = Factory.make("dog") # okay.
> var dog = Factory.make("dog") # okay.
On 09/10/2015 17:26, John Michael Lafayette wrote:
I would like Python to have a strong typing feature that can co-exist
with the current dynamic typing system. Currently Python is like this:
var animal = Factory.make("dog") # okay.
var dog = Factory.make("dog") # okay.
var
On 09/10/2015 17:03, John Michael Lafayette wrote:
I would like Python to have a strong typing feature that can co-exist
with the current dynamic typing system. Currently Python is like this:
var animal = Factory.make("dog") #okay
var dog = Factory.make("dog") #okay
As Ben Finney has all read
41 matches
Mail list logo
