View mode: basic / threaded / horizontal-split · Log in · Help
November 30, 2009
Re: dynamic classes and duck typing
Walter Bright Wrote:

> dsimcha wrote:
> > Right, but sometimes (though certainly not always) it's better to provide a
> > meta-feature that solves a whole bunch of problems (like better templates) and
> > then solve the individual problems at the library level, rather than add a
> > language feature specifically to address each need.
> 
> Yup. The hard part, though, is figuring out what the magic set of 
> seminal features should be.
> 
> 
> > One thing D does very well is
> > allow you to do the same kind of metaprogramming solutions you would do in C++,
> > except that the result doesn't suck.  For example, std.range implements
> > functional-style lazy evaluation as a library, and does it well.  The point is
> > that, if you can't deal with the complexity of having real templates, you better
> > be prepared for the complexity created by not having them.
> 
> Right. A "simple" language pushes the complexity onto the programmer, so 
> he has to write complicated code instead. D programs tend to be 
> dramatically shorter than the equivalent C++ one.
> 
> 
> > Having never done it before, I really cannot imagine how people get any work done
> > in a language that doesn't have either duck typing or good templates.  It's just
> > too rigid.  It seems like modern statically typed languages like Java and C# end
> > up adding tons of ad-hoc workarounds for lacking either of these as
> > well-integrated language features.  The best/worst example is auto-boxing.
> 
> I tried programming in Java.
> 
> A friend of mine had an unexpected insight. He used Java a lot at a 
> major corporation. He said an IDE was indispensable because with "one 
> click" you could generate a "hundred lines of code". The light bulb came 
> on. Java makes up for its lack of expressiveness by putting that 
> expressiveness into the IDE!
> 
> In D, you generate that hundred lines of code with templates and mixins.

I'm a Java programmer. IMO, the biggest problem with Java is not the language expressiveness, but poorly written APIs and badly selected abstractions. The reason I can't program in Java without an IDE is (usually) not because I need to generate tons of code, but because I'm constantly looking up new method/class names, looking up packages to export and refactoring.

A lot of things that require extensive code generation do so simply because they are badly designed. Web services (SOAP based) are a good example of that. In the end, it's just reading and writing text to a socket. It could be very simple, but it isn't.

An area when I find myself using code generation a lot is exception handling. I prefer to write my code without handling exceptions at all, and then let API to generate try/catch blocks. I tweak then afterward. Thing is, Java supports runtime exceptions that don't cascade in kilobytes of mostly useless code. People just don't use them that often.

My point is, language is one thing, but "language culture" is another. For some reason Java bred a culture that encourages bloated, counter-intuitive, "enterprise" solutions. It's not inherent in the language. It has more to do with the companies that use it, core API design and design of popular libraries. At least that's the way I see it.
November 30, 2009
Re: dynamic classes and duck typing
Roman Ivanov wrote:
> My point is, language is one thing, but "language culture" is
> another. For some reason Java bred a culture that encourages bloated,
> counter-intuitive, "enterprise" solutions. It's not inherent in the
> language. It has more to do with the companies that use it, core API
> design and design of popular libraries. At least that's the way I see
> it.

I know what you mean. I even found the file I/O Java library routines to 
be impenetrable.
November 30, 2009
Re: dynamic classes and duck typing
== Quote from Roman Ivanov (x@y.z)'s article
> Walter Bright Wrote:
> > dsimcha wrote:
> > > Right, but sometimes (though certainly not always) it's better to provide a
> > > meta-feature that solves a whole bunch of problems (like better templates) and
> > > then solve the individual problems at the library level, rather than add a
> > > language feature specifically to address each need.
> >
> > Yup. The hard part, though, is figuring out what the magic set of
> > seminal features should be.
> >
> >
> > > One thing D does very well is
> > > allow you to do the same kind of metaprogramming solutions you would do in C++,
> > > except that the result doesn't suck.  For example, std.range implements
> > > functional-style lazy evaluation as a library, and does it well.  The point is
> > > that, if you can't deal with the complexity of having real templates, you better
> > > be prepared for the complexity created by not having them.
> >
> > Right. A "simple" language pushes the complexity onto the programmer, so
> > he has to write complicated code instead. D programs tend to be
> > dramatically shorter than the equivalent C++ one.
> >
> >
> > > Having never done it before, I really cannot imagine how people get any work
done
> > > in a language that doesn't have either duck typing or good templates.  It's just
> > > too rigid.  It seems like modern statically typed languages like Java and C# end
> > > up adding tons of ad-hoc workarounds for lacking either of these as
> > > well-integrated language features.  The best/worst example is auto-boxing.
> >
> > I tried programming in Java.
> >
> > A friend of mine had an unexpected insight. He used Java a lot at a
> > major corporation. He said an IDE was indispensable because with "one
> > click" you could generate a "hundred lines of code". The light bulb came
> > on. Java makes up for its lack of expressiveness by putting that
> > expressiveness into the IDE!
> >
> > In D, you generate that hundred lines of code with templates and mixins.
> I'm a Java programmer. IMO, the biggest problem with Java is not the language
expressiveness, but poorly written APIs and badly selected abstractions. The
reason I can't program in Java without an IDE is (usually) not because I need to
generate tons of code, but because I'm constantly looking up new method/class
names, looking up packages to export and refactoring.
> A lot of things that require extensive code generation do so simply because they
are badly designed. Web services (SOAP based) are a good example of that. In the
end, it's just reading and writing text to a socket. It could be very simple, but
it isn't.
> An area when I find myself using code generation a lot is exception handling. I
prefer to write my code without handling exceptions at all, and then let API to
generate try/catch blocks. I tweak then afterward. Thing is, Java supports runtime
exceptions that don't cascade in kilobytes of mostly useless code. People just
don't use them that often.
> My point is, language is one thing, but "language culture" is another. For some
reason Java bred a culture that encourages bloated, counter-intuitive,
"enterprise" solutions. It's not inherent in the language. It has more to do with
the companies that use it, core API design and design of popular libraries. At
least that's the way I see it.

Yes, but in my (possibly somewhat uninformed) opinion, the root cause of this is
that Java just doesn't provide many tools for managing complexity.  Complexity has
to go somewhere, and about the only tool Java provides for managing it is OO-style
class hierarchies.  I have nothing against OO, classes, interfaces, inheritance,
etc.  It's just that it's not the right tool for every job.  If your problem
doesn't fit neatly into an OO-style class hierarchy, it will be made to fit
sloppily.  In a more multi-paradigm language, you might use templates, or duck
typing, or higher-order functions, or closures, or eval statements, or mixins, or
macros, or whatever complexity management system maps best to the problem you're
trying to solve.  In Java, by going overboard on making the core language simple,
you end up pushing all the complexity into the APIs.
November 30, 2009
Re: dynamic classes and duck typing
dsimcha wrote:
> In Java, by going overboard on making the core language simple,
> you end up pushing all the complexity into the APIs.

Yup, and that's the underlying problem with "simple" languages. 
Complicated code.
December 01, 2009
Re: dynamic classes and duck typing
Walter Bright wrote:
> dsimcha wrote:
>> In Java, by going overboard on making the core language simple,
>> you end up pushing all the complexity into the APIs.
> 
> Yup, and that's the underlying problem with "simple" languages. 
> Complicated code.

I think users of scripting languages would disagree with you.
December 01, 2009
Re: dynamic classes and duck typing
grauzone wrote:
> Walter Bright wrote:
>> dsimcha wrote:
>>> In Java, by going overboard on making the core language simple,
>>> you end up pushing all the complexity into the APIs.
>>
>> Yup, and that's the underlying problem with "simple" languages. 
>> Complicated code.
> 
> I think users of scripting languages would disagree with you.

PHP?
December 01, 2009
Re: dynamic classes and duck typing
Tue, 01 Dec 2009 01:08:11 -0800, Walter Bright wrote:

> grauzone wrote:
>> Walter Bright wrote:
>>> dsimcha wrote:
>>>> In Java, by going overboard on making the core language simple, you
>>>> end up pushing all the complexity into the APIs.
>>>
>>> Yup, and that's the underlying problem with "simple" languages.
>>> Complicated code.
>> 
>> I think users of scripting languages would disagree with you.
> 
> PHP?

Php is a terrible joke built by a novice http://tnx.nl/php.html. Fans of 
e.g. ruby, python etc. could argue that their language has less corner 
cases and more uniform features, which makes the development more of a 
joy to do and code less verbose. Instead of two variations, in many cases 
there is only one choice - e.g.

- type known at runtime/compile time -> known at runtime
- generic type / ordinary type -> runtime dynamic type
- primitives/objects -> everything is an object
- special set of built-in operators / normal methods -> everything is a 
message
- static classes / objects -> objects (some are singletons but can 
inherit from interfaces etc. unlike statics in d)
- free functions / methods / static methods -> methods (the modules are 
singleton objects -> free functions are module methods)
- functions / delegates -> functions
- special set of built-in control structures -> simple primitive (e.g. 
recursion & library defined structures)
- statements / expressions -> everything is an expression (this unifies 
e.g. if-then-else and a ? b : c)
- built-in AA, array, list etc. -> library defined collections
- dozens of primitive number types -> fixed size int & float (e.g. 32bit 
int and 64bit float), arbitrary precision int & float (rational type)

Overall these simplifications don't remove any crucial high level 
language features, in fact they make the code simpler and shorter. For 
instance there isn't high level code that can only be written with 8-bit 
byte primitives, static methods or closures, but not with 32-bit generic 
ints, singletons, and generic higher order functions. The only thing you 
lose is some type safety and efficiency.
December 01, 2009
Re: dynamic classes and duck typing
grauzone wrote:

> Walter Bright wrote:
>> dsimcha wrote:
>>> In Java, by going overboard on making the core language simple,
>>> you end up pushing all the complexity into the APIs.
>> 
>> Yup, and that's the underlying problem with "simple" languages.
>> Complicated code.
> 
> I think users of scripting languages would disagree with you.

Do you mean scripting languages such as Lua or ruby and python? The latter 
two are by no means simple languages, they pack tons of features.
December 01, 2009
Re: dynamic classes and duck typing
retard wrote:
> Overall these simplifications don't remove any crucial high level 
> language features, in fact they make the code simpler and shorter. For 
> instance there isn't high level code that can only be written with 8-bit 
> byte primitives, static methods or closures, but not with 32-bit generic 
> ints, singletons, and generic higher order functions. The only thing you 
> lose is some type safety and efficiency.

I'm no expert on Python, but there are some things one gives up with it:

1. the ability to do functional style programming. The lack of 
immutability makes for very hard multithreaded programming.

2. as you mentioned, there's the performance problem. It's fine if you 
don't need performance, but once you do, the complexity abruptly goes 
way up.

3. no contract programming (it's very hard to emulate contract inheritance)

4. no metaprogramming

5. simple interfacing to C

6. scope guard (transactional processing); Python has the miserable 
try-catch-finally paradigm

7. static verification

8. RAII

9. versioning

10. ability to manage resources directly

11. inline assembler

12. constants
December 01, 2009
Re: dynamic classes and duck typing
Walter Bright wrote:
> retard wrote:
>> Overall these simplifications don't remove any crucial high level 
>> language features, in fact they make the code simpler and shorter. For 
>> instance there isn't high level code that can only be written with 
>> 8-bit byte primitives, static methods or closures, but not with 32-bit 
>> generic ints, singletons, and generic higher order functions. The only 
>> thing you lose is some type safety and efficiency.
> 
> I'm no expert on Python, but there are some things one gives up with it:
> 
> 1. the ability to do functional style programming. The lack of 
> immutability makes for very hard multithreaded programming.
> 
> 2. as you mentioned, there's the performance problem. It's fine if you 
> don't need performance, but once you do, the complexity abruptly goes 
> way up.
> 
> 3. no contract programming (it's very hard to emulate contract inheritance)
> 
> 4. no metaprogramming
> 
> 5. simple interfacing to C
> 
> 6. scope guard (transactional processing); Python has the miserable 
> try-catch-finally paradigm
> 
> 7. static verification
> 
> 8. RAII
> 
> 9. versioning
> 
> 10. ability to manage resources directly
> 
> 11. inline assembler
> 
> 12. constants

I mostly agree, but python actually has a rather elegant version of RAII.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home