subject:"Re\: Stupid Language Designer Tricks"

Re: Stupid Language Designer Tricks

2012-06-14 Thread Peter da Silva


On 2012-06-13, at 10:41, David Cantrell wrote:

 On Wed, Jun 13, 2012 at 06:55:31AM -0500, Peter da Silva wrote:
 On 2012-06-11, at 13:08, Aaron J. Grier wrote:
 On Sat, May 19, 2012 at 03:49:15PM -0500, Peter da Silva wrote:
 On 2012-05-19, at 11:43, Michael G Schwern wrote:
 Or still using it, basically unchanged, as our primary system
 programming language in 2012.

 Yeh, it really sucks that in 50 years nobody has ever been able to
 develop a genuinely better alternative.

 is it because there are not genuinely better alternatives, or the cost
 of moving to them is too high?

 I don't know. I'm still waiting for someone to show me one.

 My first impressions of Go are good, but that means it's off-topic.

It looks way too high level to replace 'C'.

Oh, sorry, I mean optional semicolons? rant rant!

Re: Stupid Language Designer Tricks

2012-06-13 Thread Peter da Silva

On 2012-06-11, at 13:08, Aaron J. Grier wrote:
 On Sat, May 19, 2012 at 03:49:15PM -0500, Peter da Silva wrote:
 On 2012-05-19, at 11:43, Michael G Schwern wrote:
 Or still using it, basically unchanged, as our primary system
 programming language in 2012.

 Yeh, it really sucks that in 50 years nobody has ever been able to
 develop a genuinely better alternative.

 is it because there are not genuinely better alternatives, or the cost
 of moving to them is too high?

I don't know. I'm still waiting for someone to show me one.

Re: Stupid Language Designer Tricks

2012-06-13 Thread David Cantrell

On Wed, Jun 13, 2012 at 06:55:31AM -0500, Peter da Silva wrote:
 On 2012-06-11, at 13:08, Aaron J. Grier wrote:
  On Sat, May 19, 2012 at 03:49:15PM -0500, Peter da Silva wrote:
  On 2012-05-19, at 11:43, Michael G Schwern wrote:
  Or still using it, basically unchanged, as our primary system
  programming language in 2012.
  Yeh, it really sucks that in 50 years nobody has ever been able to
  develop a genuinely better alternative.
  is it because there are not genuinely better alternatives, or the cost
  of moving to them is too high?
 I don't know. I'm still waiting for someone to show me one.

My first impressions of Go are good, but that means it's off-topic.

-- 
David Cantrell | London Perl Mongers Deputy Chief Heretic

Aluminum makes a nice hat.  
All paranoids will tell you that.
But what most do not know 
Is reflections will show
On the CIA's evil landsat.

Re: Stupid Language Designer Tricks

2012-06-11 Thread Aaron J. Grier

On Sat, May 19, 2012 at 03:49:15PM -0500, Peter da Silva wrote:
 On 2012-05-19, at 11:43, Michael G Schwern wrote:
  Or still using it, basically unchanged, as our primary system
  programming language in 2012.
 
 Yeh, it really sucks that in 50 years nobody has ever been able to
 develop a genuinely better alternative.

is it because there are not genuinely better alternatives, or the cost
of moving to them is too high?

50 years of legacy code seems a difficult (if not impossible) momentum
to overcome.

-- 
  Aaron J. Grier | Not your ordinary poofy goof. | agr...@poofygoof.com

Re: Stupid Language Designer Tricks

2012-05-23 Thread Robert Rothenberg


On 14/05/12 17:28 Luke Kanies wrote:

On May 14, 2012, at 9:06 AM, Robert Rothenberg wrote:



[Snip!]



But Puppet is special in that it's intended to be a *descriptive* language.
So you describe how your servers are to be configured.

Sounds nice, except... it has side effects. Which makes the whole
descriptive vs imperative thing to be worthless.


Hmm.  I don't see side effects anywhere, just stupid language stuff.


Well, putting on my language theorist's hat: if the language is descriptive,
then the interpreter should do exactly what is described. If unexpected
things happen (like variables sometimes being undefined/blank because of
non-deterministic evaluation order), then those are side effects.


One example of my hatred for Puppet:

1. Execution order is non-deterministic. Well, not a problem, but…


Well, technically, the execution order of unrelated resources was, until 
recently, as random and inconsistent as the hashing algorithm in ruby.  It is 
now random (again, only for unrelated resources) but consistent across runs.


2. Evaluation order of parameters is also non-deterministic. Well,
  not as well documented, but is a bit more problematic because…


Hmm.  I was going to say that's not true, but that actually is true for the 
parameters in your example. (One of the stupidest parts of Puppet is the 
inconsistencies between types defined in the language, like below, and those 
defined in Ruby.)


Well, there's an outstanding request for a strict mode in Puppet.

Another idea would be to have it determine dependencies between parameters
based on variable interpolation, or even just to evaluate the parameters in
the order that they are specified.

I actually think that defaulting to the order that things are given in the
source code when there are no other dependencies is a good thing.


3. Undefined values are *silently* interpolated as empty strings!


I chose this because the shell does the same thing, and I figured sysadmins 
(our target user) would find it most convenient.  I think this is being 
reconsidered, but I'm not sure it doesn't actually make the most sense.  It's 
not up to me any more, though. :)


I can understand the decision, but I don't think it's good to replicate bad
behaviour on other systems, just because that's what users are used to.

Re: Stupid Language Designer Tricks

2012-05-22 Thread Tony Finch

Michael G Schwern schw...@pobox.com wrote:

 The third is distraction.  For some reason every language which started out to
 replace C gets distracted by dreams of being an application language.  I'm
 thinking Java (was originally supposed to run on set top boxes), Objective-C
 and C++  It is particularly curious that we haven't had a serious attempt in
 thirty years.  There's something about writing a pure system programming
 language that invites distraction.

Objective-C and C++ were intended to adapt C to be better for application
programming.

A more recent example of your observation is Go, though perhaps they are
using a strange definition of systems programming language. Perhaps also
(Digital Mars) D.

Rust is interesting.

The VPRI work on high-functionality small-LOC software is using a
Smalltalk-alike as its system programming language - e.g. metacircular
method dispatch.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Lundy, Fastnet, Irish Sea: Variable, mainly southerly, 3 or 4, backing
southeast 5 or 6 in Fastnet. Smooth or slight, but slight or moderate in
Fastnet. Fog patches, occasional drizzle. Moderate or good, occasionally very
poor.

Re: Stupid Language Designer Tricks

2012-05-21 Thread Tony Finch

Peter da Silva pe...@taronga.com wrote:

 I'll give you the fall-through in case.

There are some other things that were fixed in later versions:

Single namespace for structure and union members
No function argument type checking

There are some things that haven't been fixed:

const
Operators (particularly *  | ^)

And some things that have been fixed in C++

enum checking


A lot of the problems with C are due to the extremely small computer that
it had to fit into in the early days. The other contemporary languages
that we have been comparing it with ran on much bigger machines.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
South-east Iceland: Easterly or northeasterly 6 to gale 8, veering
southeasterly 5 or 6. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

Re: Stupid Language Designer Tricks

2012-05-21 Thread Michael G Schwern

On 2012.5.20 4:40 AM, Peter da Silva wrote:
 Smalltalk was also not low level enough to be used as an alternative to C.
 It wouldn't even fit in the PDP-11 they started with.

Never claimed it was.


 The list was done evaluating C as a language we use and are heavily 
 influenced
 by in 2012.
 
 And why is that? Why hasn't anything that's _genuinely_ better caught on?

Just because something is the default, or even a category killer, doesn't mean
it doesn't have some glaring faults.  We should particularly look our defaults
straight in the eye and ask if we're using it because its great or because its
what we know.  Understanding your tools flaws is as important as understanding
its strengths.

I'll have a go though.

The first is the enemy of the best is good enough and C was good enough...
for a time.  It solved a problem (portable machine programming) better and
faster than its contemporaries and even much later languages.

The second is longevity.  It's only been in the last ten years that hardware
has become so cheap and powerful that we no longer have to be concerned with
performance at every level (alternatively, that CPU and memory are no longer
the bottleneck).  Thirty years is a long time to get entrenched and have the
entire industry wrap itself around a technology.

The third is distraction.  For some reason every language which started out to
replace C gets distracted by dreams of being an application language.  I'm
thinking Java (was originally supposed to run on set top boxes), Objective-C
and C++  It is particularly curious that we haven't had a serious attempt in
thirty years.  There's something about writing a pure system programming
language that invites distraction.

The fourth is that for 99% of developers, C is not an issue.  They've solved
the problem of C by writing in higher level languages and leaving it to a
handful of others to worry about writing their language or tool in C.  There's
no great drive to fix the problem, for most folks it isn't a problem.  This
isn't necessarily the most healthy way to manage your technical development,
see also IPv6.

Fifth, I think there's a broad overlap between people who want to write at
the system level and people who want to be really close to the hardware, C
fits this mentality.  The longer the two are wielded together, the more the
system programming community will think in C.

This is a personal observation, folks to code C like details of bits and
registers and hardware details and such.  They like to feel in total control
(even if an advanced compiler means they're not).  If your system language
tries to abstract this, a lot of systems people won't touch it.  Myself?  I'd
like to be able to work my languages and operating systems and databases
without having to care about hardware.  But C won't let me do that, so I
ignore system programming.

Finally, C has a TOTAL lock on the subject.  Application programming has
always been multilingual, and ready to accept new languages, but systems
programming is nothing but C.  None of the disruptive technologies which have
created new niches for application languages (mobile, web, desktops, cheap
RAM, cheap CPU, Unicode, new operating systems, multiple CPUs, corporate power
plays) seem to be creating the new niches at the system level.  Maybe they
just don't have as big an impact.  Maybe system programmers are used to their
language being kinda clunky.  Maybe C is just very adaptable because their
standard features and libraries are so slim.  Probably a bit from all that.
It's very difficult to get a break in a decades old monoculture.


-- 
s7ank: i want to be one of those guys that types s/jjd//.^$ueu*///djsls/sm.
   and it's a perl script that turns dog crap into gold.

Re: Stupid Language Designer Tricks

2012-05-21 Thread David Parsons



On May 21, 2012, at 2:22 PM, Michael G Schwern wrote:


This is a personal observation, folks to code C like details of bits and
registers and hardware details and such.


   Novices like to prattle on about C being just another assembly
language, but they don't know what they're talking about.  It's like
hipsters talking about the philosophical purity of fixed-gear bicycles,
and should be treated with the same contempt (but these days, now that
there are more thrice-damned vanity languages out there than you can
shake a stick at, about the only people chattering on about how C is
a glorified assembly language are the people who are trying to dump on
C because it's not Perl, P*th*n, or any of those other tdvls.



I'd like to be able to work my languages and operating systems and databases
without having to care about hardware.  But C won't let me do that,



   I've programmed primarily in C for the past 30 years now, and I've
never given a damn about the hardware.   If I have to poke at hardware,
I do it in assembly language like G-d Himself intended, and leave C for
high-level work.



Finally, C has a TOTAL lock on the subject.


   No it doesn't.  You don't have to dig very deeply to find
systems that have huge gobs of code written in C++, ObjC,
PL/I(excuse me, PL/X) or, godhelpus, BLISS. It's not C's
fault that it's a more expressive language than any of these
alternatives.


   -david parsons

Re: Stupid Language Designer Tricks

2012-05-21 Thread Peter da Silva

On 2012-05-21, at 16:22, Michael G Schwern wrote:

The first is the enemy of the best is good enough and C was good enough...
for a time. It solved a problem (portable machine programming) better and
faster than its contemporaries and even much later languages.

Not just good enough, I used several of its competitors, both structured
languages and macro-assembler level alternatives. It was enormously better, and the few
that had advantages over C in a few areas had huge lacunae elsewhere.

It also actually addressed many of the problems you listed significantly better
than the majority of the alternatives, in that it at least tried to address
them, even if only to place them explicitly outside the scope of the language.

But, yeh, it's hard to move C now. But that wasn't always the case.

So forget the last 30 years. Let's set the wayback machine for the late '70s.

Why didn't anyone come up with a better alternative to C 30 years ago, when it wasn't so
entrenched? I know people tried. I was a total language geek back then (to the extent that I showed
up in the Berkeley version of Adventure as a substitute dwarf, the mad Australian on a
skateboard who throws a stack of Adventure printouts in many different languages at
you), and I desperately jumped on everything that wasn't C. I skipped at least one course at
Berkeley because it was in C, and waited for a professor who was teaching it in something else.

For a while I was hopeful about Modula, until I bought two different Modula-2
compilers for the Amiga and discovered it was pretty much impossible to write a
non-trivial Modula-2 program that would compile on both of them. Modula-3 only
had better success because it was basically a front end to C.

86 matches

Mail list logo