Microsoft debuts Bosque – a new programming language with no loops, inspired by TypeScript Microsoft Research has introduced a new open source programming language called Bosque that aspires to be simple and easy to understand by embracing algebraic operations and shunning techniques that create complexity. Bosque was inspired by the syntax and types of TypeScript and the semantics of ML and Node/JavaScript. It's …
> And doesn't MS already have a functional language with F?
F#.
And it is a hybrid functional language (so does support mutable state) and also built on ML, This sounds much more hard core...
Of course saying "no mutable state" missed the point of the real world being mutable – the cupcake I just ate has changed and I can't eat it again. But, for much data processing working on a basis of transforming data into a new state only actually needs to mutate (the persisted) data at the final step and thus is far easier to scale out processing.
"No mutable state" doesn't necessarily miss that point. In the Haskell paradigm, eating your cupcake simply created a new universe containing no cupcake. Don't worry about the old universe, the garbage collector takes care of that.
(I'm not even joking, the IO monad's definition involves a value of type RealWorld.)
It seems to have some similarities in concept to APL.
The big drawback with APL is you need a special keyboard (or stickers) and golfball (for your IBM 2741). Now that we're not constrained by character sets and have touch screens, I'd have thought it could make a comeback - it certainly looks more elegant than the C-derived syntax of Bosque.
any programming language I used from a Microsoft interface had problems indicating errors - always saying it was a 'For Next' error instead of something else - perhaps better error checking.
But then If AI were writing code it may be reasonable to have no loops present as it could facilitate faster writing, reading and analysis / errorchecking
So no object instances then. Sorry, but trying to simplify validation, a task that can be automated, forgets that we've got machines to do that. The difficult bit of coding needs to allow for complexity as the world we're working in is complex. There are of course so many things that can go wrong, which is why structured programming helps turn a soup of code into modules with, err, structure to contain our many egregious errors.
I'm just off to rebuild Notre Dame, using only Lego 'cos that system means I can't heap bricks up randomly and I'm sure having to work around the limitations of Lego will be a pain worth having. Or not.
"There are of course so many things that can go wrong, which is why structured programming helps turn a soup of code into modules with, err, structure to contain our many egregious errors."
But what happens when the structure itself introduces things like gestfaults where each model claims to be clean but once they're strung together everything goes wrong for mysterious reasons?
What the hell is a gestfault?
Anyway, if things go wrong when modules are plugged together then thats a fault of the design, not the language. Functional languages don't magically make program design any simpler, in fact if anything the opposite is true for anything other than small mathematical problems. Functional doesn't get rid of loops, it just turns them into recursion which simply confuses the design for systems that are not by nature recursive and if a language doesn't naturally map onto the problem space its trying to solve then its not a good solution to the problem.
"What the hell is a gestfault?"
I am assuming that it is a collision between Gestalt and Fault !!!???
therefore
"A fault or 'set' of faults that are greater than the individual smaller faults that have combined when all the modules of code etc are 'working' together."
That's exactly it and one reason unit testing can never find ALL the faults. The individual units themselves may test all clean, but once you put them all together the interactivity between them produces faults that would never be seen in any individual unit. A fault that's greater than the sum of its units; thus a gestalt fault or "gestfault".
"Presently, Bosque relies on an interpreter written in TypeScript, run on Node.js"
Doesn't that pretty much say it all? (I hear a loud 'Eeewwww')
How long before Micro-shaft starts CRAMMING it at us like:
a) Windows 10 and "the Store"
b) ".Net"
c) C-pound
d) Silverlight
e) 'the Metro' and UWP (in general)
f) A DevStudio that requires EXCESSIVE mousie-clickie in a "property sheet" instead of the old-style tabbed dialog boxen (with easiy discovered hot keys) that you used to see in the dialog editor and class wizard of earlier VC++ IDEs...
etc.
And how is this better than Python for doing that sort of thing?
And what's wrong with a loop?
and don't EVEN get me started about un-typed data storage and garbage collection... which from what I can tell, seem to be unspoken 'features'.
When I was a student I was in an industrial placement and tasked with writing a programme to control some kit on an IEEE bus and print the output on the brand new and magical HP Plotter (more watchable than Game of Thrones). The language was the lovely HP Basic (no sarcasm there) and I set off and wrote the programme. It worked OK - then the rest of the lab spent their lunch hours ripping it to shreds for being "unstructured". I took this pretty seriously, so spent some time getting rid of all the Gotos and "bad" loops, etc. until it met their view of what a properly structured programme should look like. It still worked in the end, but I don't think it was much better. My analogy for the GoTo is it's a bit like Jaunting: you can either spend ages driving round the one-way system but if you could Jaunt like the Tomorrow People then surely you would.
The problem with "goto" is not its effectiveness - hell that is exactly how flow control happens in the generated assembler/object code - but in another human reading it and upon seeing a jump destination being able to work out how many ways one gets there.
For some very small functions with a local jump (please, PLEASE, don't bring up setjump/longjump here!) it might be fine as a simple way, for example, to break out of nested loops. But on a larger scale the program's intentions become unintelligible.
Mind you, there are other constructs that are also a bit dodgy, for C you can return out of a function at any point, not always clear logic there. But $DEITY forbid you find yourself working on old FORTRAN where you can have multiple entry points to a subroutine!
It was also possible that their thought process went like "If they think this is good style, they might use a bunch of gotos in the next project, which could be much larger". Depending on whether you were going to be there for a while, they either thought "They will really hate it once this catches up to them and they have to recode something big in the future" or the more pragmatic "We will really hate it if we see this on something bigger". They could then decide that you could get experience writing in a clearer style with this relatively small project to get you used to a better way.
I did not remember the multiple entry in a subroutine, by I remember there was a feature allowing multiple return points *outside* subroutine:
- Define a parameter as a label using ad'hoc syntax
- Use a variant of return to say combine return + goto Nth label within parameter list
I still remember writing a Hadamard transform subroutine in the late-'70s/early-'80s that had two entry points. The code that performed the transform was the same for the forward and inverse transforms. Only the scale factor you applied at the end was different--all the extra entry point did was calculate the correct scale factor. Seemed better than dealing with two pieces of code that differed in only a single line.
@Paul - I agree with you that reviewing/editing/fixing "unstructured" code is a pain, especially in the old days when there were no tools, just the tiny screen of a 9826. However, the main benefit that came out of the re-work I was heckled into doing was that I was able to pull out a general purpose subroutine for driving the plotter which could be used by others in the lab - whether directly from test gear or by putting user-generated data into a defined format. It became an ongoing lunchtime project with user change requests regularly submitted for things like auto-scaling, colour options, annotation, etc. and I think that the plotter sub became larger than the control software which spawned it. I took it back to poly. when the placement finished and it was still in use a couple of years later when I left.
@Headley_Grange
HP Calculators and plotters...memories. The desktop calculaters in the early 1970s were programmable. The programs occupied register space starting with the high registers and coming down. The program could reference those registers which led to the interesting, and immediately grasped, option of modifying itself. Take the square root of R15 and see what happens next. Now hook a plotter up.... What we learnt from that was that those early plotters were tough. :)
@Andrew: I think I've posted this before - but I grew up with HP test gear and computers. They were indestructible and the best. My HP11C calculator was probably the first "very expensive and hard to justify" thing I bought and it still works. It doesn't get much use now, although the iPhone app which emulates it does.
When I bought my first laptop I saw an HP model and just bought it cos it was obviously going to be the best thing in the whole shop. What a fool. What a disappointment. What a lesson. Whatever happened to HP?
Those plotters though.
Still remember Carly giving herself (the board giving her) a 16m bonus for doing such a good job. While just months before she was asking every employee to waive a day's wages.
That money went directly from the employees' mouths to her bank account.
Morale went through the floor that day.
