Minimally Viable Team in a nutshell

Allan Kelly from Allan Kelly Associates

Workers_000011166993XSmall-2018-01-26-11-03.jpg

Last week I was in Holland helping a client with their agile adoption and digital transformation. When the subject of teams came up I started talking about Minimally Viable Teams. Yesterday I found myself writing an e-mail to the client expanding on the idea. And it seemed to me that the e-mail – or an edited version – was worth sharing here…

The idea of an Minimally Viable Team (MVT) is based on the observation that if a team is overstaffed then team members will find work for themselves – Parkinson’s Law.

Mix in Conway’s Law: the recognised phenomenon where team copy the organization structure they are in. So for example, if you have a database expert on the team the final design will use a database whether one is needed or not.

If one is aiming for a self-organizing, goal-directed, value-seeking team then making any decisions about the team, the software design, or even the problem before work begins is questionable. The more decisions that are made the more the team is constrained, the more the team is constrained the less it is master of its own destiny.

Further, those decisions made before work begins: one expects them to be rational, which means some pre-work is needed to understand what decisions are needed and make the decisions. That pre-work costs time and money. The more money that is committed then the more difficult (i.e. more career threatening) it becomes to reverse those decisions if things go wrong.

Some companies spend an awfully long time thinking and planning to do something: longer than it takes to actually do the thing. I once visited a company which had spent five years planning a particular project and not building anything.

Add two more things to this.

We know from experience that planning has rapidly diminishing returns. A little bit of planning creates great learning, but after a little while the rate of learning drops off. Very soon learning by doing becomes more effective, i.e. switch from thinking about what might be done to trying to do it.

This has never been truer than today – 2018: with the computing power and tools it is faster and cheaper than ever to build a prototype, a concept, an MVP, version 1, alpha version or whatever else you want to call it.

However, going to the other extreme and doing no pre-work doesn’t make a lot of sense either.

Enter the Minimally Viable Team: the team jumps to doing, all that pre-work is given to the team. They get to decide what is needed.

To traditionalists the team/project/product is launched prematurely but actually all we are doing is extending the start date backwards so that the pre-work is now part of the thing. By tasking the initial team with all the traditional pre-work the team becomes master of their own destiny again. And they can choose to approach the mission with a traditional approach (market research, architecture design, resource planning) or in an agile/digital fashion (build a small product and test it) – that is their choice.

The MVT idea is to “starve” the team and make them pull only the necessary resources as and when they need them. When organizations decide who (which roles) will be on the team in advance they are in effect designing the software.

And since agile approaches and modern tools allow us to make progress that much faster why not move more quickly to a working product? Minimise the design, postpone the architecture.

This approach also means the initial team can be kept small which means they are cheap. So if they conclude the project shouldn’t be done the organizational inertial is less and the project can be cancelled. Which hopefully means the organization will take more chances on more ideas.

Try this thought experiment.

On Day-Zero there is nothing.

Someone decided there should be Product X. How did this happen? They may have had the idea days ago and have spent the intervening time researching the market, the competition, the problem and so on. (During which time their normal job has been disrupted, the sooner they can dedicate themselves to the new idea the faster things will happen.)

On Day-Zero they talk to an architect who considers a design.

This takes a few days at the end of which there is an outline design and the architect suggests the team needs four programmers, two testers, a UXD and a DBA. Plus a project manager and product owner. 10 in all.

It now takes time to make the business case and gather those resources.

At that point work can officially begin, call that D-Day.

Then the team need to learn to work together, build something and launch it into a market.
They also need to understand what the architect had in mind.

Officially the project began on D-Day, or perhaps the day the business case was approved.

How much time has been spent so far? Without testing the market? Allowing competitors to do something? – all this time cost of delay has been at work changing the business case.

How has all that “getting ready” time been accounted for? How has this work been managed?

The MVT approach says: Time is of the essence the team should decide all these things.

So, as quickly as you can, spend a little venture money on an MVT.

That team has to investigate the market, competition, problem, etc. The team can think about architecture but their primary aim is to build something, and MVP, a prototype, a proof of concept, whatever – build it, show it to customers, launch it, put it in the market.

By keeping it small the team can quickly invalidate ideas which don’t work. Ideas that do work can be built on. They are free to learn.

The initial MVT will do all the same things that a “pre project” phase would do but in a much more agile/digital way. The MVT also allows for continuity, when the team find success the team that can be expanded and grown – applying Gall’s Law.

This also looks a lot more like a start-up than a normal corporate project.

If the idea of a Minimally Viable Team is new to you then check out the discussion in Continuous Digital or some of my earlier blog posts on MVTs.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post Minimally Viable Team in a nutshell appeared first on Allan Kelly Associates.

Do compilers take inline as a hint?

Simon Brand from Simon Brand

If you’ve spent any time in C or C++ communities online, you’ve probably seen someone say this:

inline used to be a hint for compilers to inline the definition, but no compilers actually take that into account any more.

You shouldn’t believe everything you see on the internet.

Of course, inline has mandatory effects on linkage and whatnot, but this post is only interested in whether or not compilers might change the decision to inline a function or not based on whether you write inline in the declaration.

However, the point of this article isn’t to give you good rules for when to use inline, because as much as I like to debate technical minutiae, your compiler will likely be a better judge than you anyway. Instead I want to show that if you want to know how compilers or standard libraries implement things, you can just go look! It might be daunting the first time, but getting a knack for finding things in large code bases and understanding your tools can pay off. I’ll be diving into the codebases for Clang and GCC to see how they handle inlining hints and hopefully convince you that you can do the same for questions which you have about your tools.


Clang

Let’s do this bottom-up. Clang is a compiler frontend for LLVM, which means that it takes C-family languages, translates them to LLVM Intermediate Representation, and LLVM handles generating assembly/binaries from that. So we can dig around in LLVM to see if we can find code which deals with inlining. I armed myself with a text editor and grep and found the following code in llvm/lib/Analysis/InlineCost.cpp:

  // Adjust the threshold based on inlinehint attribute and profile based
// hotness information if the caller does not have MinSize attribute.
if (!Caller->optForMinSize()) {
if (Callee.hasFnAttribute(Attribute::InlineHint))
Threshold = MaxIfValid(Threshold, Params.HintThreshold);
if (PSI) {
uint64_t TotalWeight;
if (CS.getInstruction()->extractProfTotalWeight(TotalWeight) &&
PSI->isHotCount(TotalWeight)) {
Threshold = MaxIfValid(Threshold, Params.HotCallSiteThreshold);
} else if (PSI->isFunctionEntryHot(&Callee)) {
// If callsite hotness can not be determined, we may still know
// that the callee is hot and treat it as a weaker hint for threshold
// increase.
Threshold = MaxIfValid(Threshold, Params.HintThreshold);
} else if (PSI->isFunctionEntryCold(&Callee)) {
Threshold = MinIfValid(Threshold, Params.ColdThreshold);
}
}
}

By just looking at this code without knowledge of all the other functions, we won’t be able to totally understand what it’s doing. But there’s certainly some information we can gleam here:

    if (Callee.hasFnAttribute(Attribute::InlineHint))
Threshold = MaxIfValid(Threshold, Params.HintThreshold);

So now we know that LLVM takes the presence of an inlinehint attribute into account in its inlining cost model. But does Clang produce that attribute? Let’s look for that attribute in the Clang sources:

    // Otherwise, propagate the inline hint attribute and potentially use its
// absence to mark things as noinline.
if (auto *FD = dyn_cast<FunctionDecl>(D)) {
if (any_of(FD->redecls(), [&](const FunctionDecl *Redecl) {
return Redecl->isInlineSpecified();
})) {
B.addAttribute(llvm::Attribute::InlineHint);
} else if (CodeGenOpts.getInlining() ==
CodeGenOptions::OnlyHintInlining &&
!FD->isInlined() &&
!F->hasFnAttribute(llvm::Attribute::AlwaysInline)) {
B.addAttribute(llvm::Attribute::NoInline);
}
}

The above code from clang/lib/CodeGen/CodeGenModule.cpp shows Clang setting the inlinehint attribute. It will also possibly mark declarations as noinline if inline was not supplied (depending on compiler flags). Now we can look for code which affects isInlineSpecified:

// clang/include/clang/Sema/DeclSpec.h
bool isInlineSpecified() const {
return FS_inline_specified | FS_forceinline_specified;
}

// clang/lib/Sema/DeclSpec.cpp
bool DeclSpec::setFunctionSpecInline(SourceLocation Loc, const char *&PrevSpec,
unsigned &DiagID) {
// 'inline inline' is ok. However, since this is likely not what the user
// intended, we will always warn, similar to duplicates of type qualifiers.
if (FS_inline_specified) {
DiagID = diag::warn_duplicate_declspec;
PrevSpec = "inline";
return true;
}
FS_inline_specified = true;
FS_inlineLoc = Loc;
return false;
}

// Parse/ParseDecl.cpp:ParseDeclarationSpecifiers
case tok::kw_inline:
isInvalid = DS.setFunctionSpecInline(Loc, PrevSpec, DiagID);
break;

The above snippets show the functions which set and retrieve whether something was specified as inline, and the code in the parser which calls the setter.

So now we know that Clang propagates the presence of the inline keyword through to LLVM using the inlinehint attribute, and that LLVM takes this into account in its cost model for inlining. Our detective work has been successful!


GCC

How about GCC? The source for GCC is a fair bit less accessible than that of LLVM, but we can still make an attempt. After a bit of searching, I found that the DECL_DECLARED_INLINE_P macro seemed to be used lots of places which were relevant. So we can look for where that’s set:

        // c/c-decl.c:grokdeclarator

/* Record presence of `inline' and `_Noreturn', if it is
reasonable. */

if (flag_hosted && MAIN_NAME_P (declarator->u.id))
{
if (declspecs->inline_p)
pedwarn (loc, 0, "cannot inline function %<main%>");
if (declspecs->noreturn_p)
pedwarn (loc, 0, "%<main%> declared %<_Noreturn%>");
}
else
{
if (declspecs->inline_p)
/* Record that the function is declared `inline'. */
DECL_DECLARED_INLINE_P (decl) = 1;
if (declspecs->noreturn_p)
{
if (flag_isoc99)
pedwarn_c99 (loc, OPT_Wpedantic,
"ISO C99 does not support %<_Noreturn%>");
else
pedwarn_c99 (loc, OPT_Wpedantic,
"ISO C90 does not support %<_Noreturn%>");
TREE_THIS_VOLATILE (decl) = 1;
}
}

We can then look for uses of this macro which seem to affect the behaviour of the inliner. Here are a few:

  //ipa-inline.c:want_inline_small_function_p    

/* Do fast and conservative check if the function can be good
inline candidate. At the moment we allow inline hints to
promote non-inline functions to inline and we increase
MAX_INLINE_INSNS_SINGLE 16-fold for inline functions. */

else if ((!DECL_DECLARED_INLINE_P (callee->decl)
&& (!e->count.ipa ().initialized_p () || !e->maybe_hot_p ()))
&& ipa_fn_summaries->get (callee)->min_size
- ipa_call_summaries->get (e)->call_stmt_size
> MAX (MAX_INLINE_INSNS_SINGLE, MAX_INLINE_INSNS_AUTO))
{
e->inline_failed = CIF_MAX_INLINE_INSNS_AUTO_LIMIT;
want_inline = false;
}


//ipa-inline.c:edge_badness

/* ... and do not overwrite user specified hints. */
&& (!DECL_DECLARED_INLINE_P (edge->callee->decl)
|| DECL_DECLARED_INLINE_P (caller->decl)))))


//ipa-inline.c:early_inline_small_functions

/* Do not consider functions not declared inline. */
if (!DECL_DECLARED_INLINE_P (callee->decl)
&& !opt_for_fn (node->decl, flag_inline_small_functions)
&& !opt_for_fn (node->decl, flag_inline_functions))
continue;

That’s some evidence that the keyword is being taken into account. If we want to get a better idea of all of the effects, then we now have a starting point from which to conduct our expectations.


Conclusion

I hope I’ve managed to convince you of two things:

  1. Some modern compilers still take inline hints into account.
  2. If you want to understand how your compiler works and it’s open source, you can just go and look.

If you’re actually going to try and optimize your code using inline then Do The Right Thing And Measure It1. See what your compiler actually generates. Profile your code to make sure you’re opmitizing something that needs optimizing. Don’t guess.


  1. DTRTAMI (dee-tee-arr-tamee) kinda has a ring to it. 

Learning a cpu’s instruction set

Derek Jones from The Shape of Code

A few years ago I wrote about the possibility of secret instruction sets making a comeback and the minimum information needed to write a code generator. A paper from the sporadic (i.e., they don’t release umpteen slices of the same overall paper), but always interesting, group at Stanford describes a tool that goes a long way to solving the secret instruction set problem; stratified synthesis learns an instruction set, starting from a small set of known instructions.

After feeding in 51 base instructions and 11 templates, 1,795.42 instruction ‘formulas’ were learned (119.42 were 8-bit constant instructions, every variant counted as 1/256 of an instruction); out of a maximum of 3,683 possible instructions (depending on how you count instructions).

As well as discovering ‘new’ instructions, they also discovered bugs in the Intel 64 and IA-32 Architectures Software Developer Manuals. In my compiler writing days, bugs in cpu documentation were a pet hate (they cause huge amounts of time to be wasted).

The initial starting information used is rather large, from the perspective of understanding the instruction set of an unknown cpu. I’m sure others will be working to reduce the necessary startup information needed to obtain useful results. The Intel Management Engine is an obvious candidate for investigation.

Vendors sometimes add support for instructions without publicizing them and sometimes certain bit patterns happen to do something sensible in a particular version of a design because some random pattern of bits happens to do whatever it does without being treated as an illegal opcode. You journey down the rabbit hole starts here.

On a related note, I continue to be amazed that widely used disassemblers fail to correctly handle surprisingly many, documented, x86 opcodes; benchmarks from 2010 and 2016

How to enable logging in the MongoDB Java driver

Timo Geusch from The Lone C++ Coder&#039;s Blog

I will show you how to enable logging in the MongoDB Java driver and also how to set and change the log level. The official mongoDB Java driver uses java.util.logging as its default logging framework or sl4j if the latter is present. It can be very useful to enable logging in the MongoDB drivers to […]

The post How to enable logging in the MongoDB Java driver appeared first on The Lone C++ Coder's Blog.

Questions and answers about Pepper3

Andy Balaam from Andy Balaam&#039;s Blog

Series: Examples, Questions

My last post Examples of Pepper3 code was a reply to my friend’s email asking what it was all about. They replied with some questions, and I thought the questions and answers might shed some more light:

Questions!

Brilliant ones, thanks.

In general though you’ve said a lot about what Pepper can do without giving design decisions.

Yep, total brain dump.

Remind me again who this language is for :)

It’s a multi-paradigm (generic, functional, OO) language aimed at application programmers who want:

  • “native” performance on their chosen platform (definitely including actual native machine code). This is inspired by C++.
  • easy deployment (preferably a single binary containing everything, with an option to link most dependencies statically), including packaging of installers for major OSes. This is inspired by C++, and the pain of C++.
  • perfect flexibility for creating types – “meta-programming” is just programming. Things you would have done using code generation (e.g. generating a class hierarchy from an XSD) are done by running arbitrary code at compile time. The powerful type system is inspired by Haskell and the book “Modern C++ Design”, and the meta-programming is inspired by Lisp.
  • Simple memory management without GC through ownership. This is inspired by modern C++, and then Rust came along and implemented it before I could, thus proving it works. However, I would remove a lot of the functionality in Rust (lifetimes) to make it much simpler.
  • Strong support for functional programming if you want it. This is inspired by Haskell.
  • The simplest possible core language, with application programmers able to expand it by giving them the same tools as the language designers – e.g. “for” is just a function, so you can make your own. I am hoping I can even make “class” a function. This is inspired by Lisp, and oppositely-inspired by Java.
  • Separation between the idea of Interfaces, which I think I will call “type specifiers” (and will allow arbitrary code execution to determine whether a type satisfies the requirements) and structs/classes, allowing us to make new Interfaces and have old code satisfy them, meaning we can do generic stuff with e.g. ints even if
    no-one declared that “class Int : public Quaternion” or whatever.
  • Lots of “nudges” towards things that are good: by default things will be functional and immutable – you will have to explicitly say if you want to use more dangerous constructs like side effects and mutable values.
  • No implicit conversions, or really anything happening without you saying so.

Can you assign floats to ints or vice versa?

Yes, but you shouldn’t.

If you’re setting types in code at the start of a file, is this only available in the main file? Are there multiple files per program? Can
you have libraries? If so, do these decide the functionality of their types in the library or does this only happen in the main file?

I haven’t totally decided – either by being enforced, or as a matter of style, you will generally do this once at the beginning of the program (and choose on the compiler command line to do it e.g. the debug way or the release way) and it will affect all of your code.

Libraries will be packaged as Pepper3 source code, so choices you make of the type of Int etc. will be reflected through the whole dependency tree. Cool, huh?

This is inspired by Python.

Can you group variables together into structs or similar?

Yes – it will be especially easy to make “value types”, and lots of default methods will be provided, that you will be strongly encouraged to use – e.g. copy and move operations. This is inspired by Elm.

Why are variables immutable by default but mutable with a special syntax? It’s the opposite of C++ const, but why that way around?

This is one of the “nudges” – immutable stuff is much easier to think about, and makes parallel stuff easier, and allows optimisations and so on, so turning it on by default means you have to choose to take the bad path, and are inclined to take the virtuous one. This is inspired by Haskell and Rust.

Why only allow assignments, function calls and operators? I’m sure you have good reasons.

To be as simple as possible, so you only have those things to learn and the rest can be understood by just reading the code. This is inspired by Python.

I wrote more of my (earlier) thoughts in this 4-post series, which is better thought through: Goodness in Programming Languages

Nature abhors an information void

Allan Kelly from Allan Kelly Associates

142px-PennyFarthing-2018-01-20-13-28.png

No. 6: What do you want?
Voice: Information
No. 6:You won’t get it
Voice: By hook or by crook we will

Information… we all want information… Facebook updates, Tweets, 24-hour rolling news, the Donald Trump Big Brother House… the opening scenes and words of The Prisoner continue to echo, Patrick McGoohan and the other writers got it right, they were just 50 years early.

Human beings have insatiable thirst for information – even when we know rationally that information is useless is pointless we still want it. We persuade ourselves that something might be happening that we need to know about.

Just today I was driving when my mobile phone started to ring. It was highly unlikely to be anything but still my mind started to think of important things it could be. I had to stop the car and try to answer it. Of course, it was spam, a junk call, caller-ID told me that so I didn’t answer.

Every one of us has information weaknesses. In part it is dopamine addiction. We may look down on those who watch “vanity metrics” but we all information fetishes whether they be, metrics, scores, “facts” or celebrity gossip.

Whether e-mail, Twitter, Facebook, WhatsApp, SMS, Slack, some other medium or social media we all need information and a dopamine fi. Has only replied to my tweet? Has anyone retweeted my last tweet? Has anyone followed me today?

Sometimes it is impossible to believe that nobody has retweeted my fantastic tweet, or that a potential client hasn’t immediately replied to an e-mail, or that… I’ve even on occasions found myself picking up my phone and going to the mail app when I’ve only just walked away from answering e-mail on my PC – as if the e-mail on my phone is better than the e-mail on my PC!

The only thing worse than having a mailbox full of unanswered e-mails is an empty mailbox – mailbox zero – which stays empty.

Sometimes one demands information when there just isn’t any. I think that is what number 6 really meant when number 2 repeatedly asked him for information: there wasn’t anything more than he had said. He had given his information, if others demanded more then it was simply because they couldn’t accept what they had been told.

I’m sure all parents have experienced children in the back of the car who ask: “Are we there yet?”. To which you reply “No – it will be at least an hour”. And then, five minutes later you hear “Are we there yet?”

And who hasn’t felt the same way about project managers? Or technical leads? Or product managers? product owners? business analysts?

Children don’t stop asking because… well, maybe because they don’t understand the answer, they have a poor concept of time. Or maybe because they really want the answer to be “Yes we are there.” As small people children also want information.

Isn’t that the same when other people ask you the “Have you finished foo yet?” and even “When will it be ready?” While one hopes they have a better concept of time they don’t necessarily take in the answer, and they hope and hope and hope that the answer will soon be the answer they want it to be. People are very bad at handling information voids.

Manager types might dress the question up in terms of “The business needs to know” how often does that disguises the real truth: somebody didn’t like the last answer and is hoping that if the question is posed again the answer might be the one they want.

The project manager who checks in every few hours is no different than the developer who leaves their e-mail open on a second screen, or the tester keeps Twitter in the background. Each of them wants to know information!

Our difficult in dealing with information voids means we constantly search for information. And if we can’t find it we create pseudo-information: time based project plans which purport to show when something will be done or system architecture documents which claim to show how everything will work. Are the project managers and architects who create these documents are just seeking information? Dopamine?

Long time readers may remember my review of time-estimation research. Some of the research I read showed that people in positions of authority, or who claimed expert knowledge, underestimates how long work will take more than the people who do the work. Researchers were not clear as to whether this effect was because those in authority and experts let their desire for the end state influence their time estimation or whether it was because these people lacked an understanding of the work in detail and so ignored complications.

And it is not just time based information. Requirements documents are often an attempt to discern how a system may be used in future. System architecture designs are an attempt to second guess how the future may unfold. Unfortunately, as Peter Drucker said “We have no facts about the future”.

Faced with an information void we fill it with conjecture.

Sadly I also see occasions where the search for answers disables people. Sometimes people search for information and answers which are within their own power to give. Consider the product owner inundated with work requests for their product. They search for someone to tell them what they should do and what they should not do. Faced with an information void they look for answer from others. But sometimes – often? always? – the answer is within: as product owner they have the authority to decide what comes first and what is left undone.

I have become convinced over the years that often people ask for information that simply doesn’t exist. When the information isn’t presented they fill in the blanks themselves, they assume the information does exist and isn’t being shared. In some cases they create conspiracy theories or they accuse others of being secretive. But because of doubt they they don’t act on the information.

It is easy to think of examples in the public eye but I think it also happens inside organizations. Often times managers really don’t know what the future will hold but if they don’t tell people then they are seen as hiding something. If they deny information exists they may be seen as stupid or misleading.

The same happens the other way around, the self same managers – who really don’t know as much as people think they do – ask programmers, testers, analysts, etc. for information which doesn’t exist and which maybe unknowable. Telling your manager “you don’t know” might not be something you feel safe doing, and if you do then they may go and ask someone else.

In almost every organization I visit people tell me “We are not very good at communicating around here.” Again and again people tell me they are not told information they “should” be told. I’ve never visited an organization where people tell me “Communication is great around here” and while I’ve visited places where people say “We have lots of pointless meetings” nobody tells me “We are told too much.”

My working assumption in these cases is simply: The information doesn’t exist.

This is Occam’s razor logic, it is conspiracy free, it doesn’t assume the worst of people. I don’t assume people are keeping information secret – either deliberately or through naive understandings of what other people want.

So, the real answer for No. 6 should be “I’ve told you the truth, maybe you can’t accept it.”

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post Nature abhors an information void appeared first on Allan Kelly Associates.

On Lucky Sevens – student

student from thus spake a.k.

The Baron's most recent game consisted of a race to complete a trick of four sevens, with the Baron dealing cards from a pristine deck, running from Ace to King once in each suit, and Sir R----- dealing from a well shuffled deck. As soon as either player held such a trick the game concluded and a prize was taken, eleven coins for the Baron if he should have four sevens and nine for Sir R----- otherwise.
The key to reckoning the equity of the wager is to note that it is unchanged should the Baron and Sir R----- take turns dealing out the rest of their cards one by one after the prize has been taken.

Examples of Pepper3 code

Andy Balaam from Andy Balaam&#039;s Blog

Series: Examples, Questions

I have restarted my effort to make a new programming language that fits the way I like things. I haven’t pushed any code yet, but I have made a lot of progress in my head to understand what I want.

Here are some random examples that might get across some of the ways I am thinking:


// You code using general types like "Int" but you can set what
// they really are in the code (usually at the beginning), so
// if you plan to use native ints in the production code, it's
// a good idea to use:
Int = CheckedNativeInt;
// while in dev, since it will crash at runtime if you overflow.

// Then, in production when you're sure you have no errors,
// switch to an unchecked one:
Int = NativeInt;

// But, if you prefer correctness over efficiency, you can use
// mathematical integer that never overflows:
Int = ArbitrarySizeInt;


// Variables are immutable by default, so:
Int x = 4;
x = 3;      // this is a compile error


// But this is OK
Mutable(Int) y = 6;
y = y + x;

// Notice that you can call functions that return types that you
// then use, like Mutable(Int) here.

// Generally, code can run at either compile time or run time.
// Code to do with types has to run at compile time.
// By default, other code runs at run time, but you can force
// it to run early if you want to.


// A main method looks like this - you get hold of e.g. stdout through
// a World instance - I try to avoid any global functions like print, or
// global variables like sys.stdout.

Auto main =
{:(World world)->Int
    //...
};

// (Although note that Int, String etc. actually are global variables,
// which is a bit annoying)

// I wish the main method were simpler-looking.  The only saving grace
// is that for simple examples you don't need a main method -
// Pepper3 just calculates the expression you provide in your file and
// prints it out.


// Expressions in curly brackets are lambda functions, so:

{3};

// is a function taking no arguments, returning 3, and:

{:(Int x)
    x * 2
};

// is a function that doubles a value.

Obviously, we can tie functions to names:

Auto dbl =
    {:(Int x)
        x * 2
    };

// Meaning we can call dbl like this:
dbl(4);

// Auto is a magic word to say ("use type inference"), so
// this is equivalent to the above:

fn([Int]->Int) dbl =
    {:(Int x)
        x * 2
    };


// Because {} makes an anon function, things like "for" can be
// functions instead of keywords.

for(range(3), {:(Int x)
    world.stdout.println(to(String)(x));
});


// As far as possible, Pepper3 will only contain assignment statements:
String s = "xx";

// and expressions containing function calls and operators:
dbl(3) + 6;


// This means we can make our own constructs like a different type of
// for loop, which would need a new keyword in some languages:

Auto parallel_for = import(multiprocess.parallel_for);