Bayle Shanks's website: proj-oot-ootNotes23

golang has:

select { case ch1 <- 0: print(0) case ch1 <- 1: print(1) case ch2 <- 2: print(2) }

where the case is randomly chosen amongst those that are ready. For example, if there is someone else at the other end of ch1 reading it, but no one reading from ch2, then either the 0 case or the 1 case will be chosen, never the 2 case.

thx [1]

---

The thing to realise about Clojure is that it isn't an open source language like Python. It is a language controlled very tightly by Rich Hickey and Cognitect. Major work is done in secret (transducers, reducers, spec), then announced to the world as a "Here it is!" and then suggestions are taken. This goes well mostly, though it took a lot of outside persuasion that Feature Expressions weren't the best idea, and to come up with Reader Conditionals instead.

---

why not clojure?

takes too long to startup
no tradition of static typing in library ecosystem (even though gradual typing available eg clojure.spec)
too many parens
- and probably too verbose for cmdline oneliners?

---

kentonv 132 days ago

parent [-]

on: E Programming Language: Write Secure Distributed S...

...

Cap'n Proto is very much E's distributed programming concepts "ported" to other languages, and Mark helped me get the details right.

Interestingly, E takes a very different approach from standard distributed systems practices today. Most distributed programming today emphasizes stateless servers performing idempotent operations on a monolithic datastore. Stateful servers are considered too hard to get right. What E did is actually provide the vocabulary needed to be able to reason about stateful servers, so you could get them right. Stateful servers are able to achieve massively better performance, especially in terms of latency, because they don't need to hit persistent storage for every single operation. You obviously need some way to deal with machine and network failures, but E provides that. "

---

this is confusing in Python: 'namedtuple' returns a class but if you forget that and think it returns and instance, some things appear to work:

n = collections.namedtuple('my_named_tuple_class', 'x')
n.x = 3
n.x = 5

---

interestingly nim has exploratory numerical computing stuff eg https://github.com/johnnovak/johnnovak.site/blob/master/blog/files/2016-09-21/src/gammatransfer.nim which i think makes the graphs on pag http://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/

---

this article is mostly a long list of complaints that JS is not staticaly typed:

https://arielelkin.github.io/articles/why-im-not-a-react-native-developer

the complaints/wishlist items are common ones but i'll still make a list b/c it helps us remember some stuff we want in oot:

"Swift is safe. The compiler won’t let you pass in an Int to a function that expects a String. In fact, if the compiler isn’t able to infer a type, you have to explicitly set it." (and he would prefer if JS were that way)
wants optionals
no support for immutable composite types (there is 'const' but it doesnt work right on eg arrays, eg you can do 'const array = [3, 6]; array[32] = 9')
no uniqueness typing
arrays are hash-like, no way to constrain them to be only array-like; eg you can do 'var array = [0,1,2]; array["hello"] = "watsup"'
any function can throw a runtime error or exception, and you can throw any type (eg a string, a Date, a function). Seems like he would prefer if the type system could tell you which things might throw.
wants support for Decimals in the std library
doesn't like how, since there is only floating point, you can't work with integers without worrying about NaNs?, which means learning counterintuitive things like NaN? != NaN?. Also, JS 'isnan' returns True if given a string.
in JS you can define a constructor but you can still create the object without calling the constructor, leading to the possibility of an object created in an uninitialized and inconsistent state, eg:

class Rectangle {
  constructor (width, height) {
    this.width = width
    this.height = height
  }
  area () {
    return width * height
  }
}

class Square extends Rectangle {
  constructor(){
    super() 
  }
}

var myRect = new Square()

console.log(myRect.area()) // ReferenceError: width is not defined

"Curly braces after an if statement are optional:

if (1 > 2) 
  console.log("ha"); console.log("he")
  console.log("hi")
  console.log("ho")

"Switch fallthrough. If you forget to include a break statement in a clause of a switch statement, you fall through. Also, a swift statement doesn’t carry out checks for case exhaustivity."
there is both 'null' but also 'undefined'
No enums
No guard statement.
No generics.
No where statement to increase expressivity of control flow statements.

e likes JS with Flow okay but wishes it were part of JS, so that the ecosystem used it more.

---

a security problem in JS (easy to obfuscate code) due to autoconversion

http://jazcash.com/a-javascript-journey-with-only-six-characters/

---

on some good things about PHP:

" ...state. Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. ... concurrency. An individual web request runs in a single PHP thread. ... Finally, the fact that PHP programs operate at a request level means that programmer workflow is fast and efficient, and stays fast as the application changes. Many developer productivity languages claim this, but if they do not reset state for each request, and the main event loop shares program-level state with requests, they almost invariably have some startup time. For a typical Python application server, e.g., the debugging cycle will look something like think; edit; restart the server...I claim that PHPs simpler think; edit; reload the page cycle makes developers more productive. "

---

" the Crystal[1] programming language, which has looked closely on mainstream programming languages and adopted the good parts of them, like Go's concurrency model, Node's asynchronous I/O, Ruby's clean & straight-forward syntax and object-orientation model and the performance and interoperability with C."

https://crystal-lang.org/

---

"...numeric computation is a potential domain of interest, and its one where "const generics" would be a great help" -- [2]

what are "const generics"? https://github.com/rust-lang/rfcs/issues/1038 suggests they are just things like SmallVec?<32>, where there is a numeric constant hardcoded into the type

---

Rust's proposed 2017 roadmap's non-goals [3] are pretty interesting in that they are diametrically opposed to my thoughts for Oot (where there is always an oot-next):

" Non-goals

Finally, it's important that the roadmap "have teeth": we should be focusing on the goals, and avoid getting distracted by other improvements that, whatever their appeal, could sap bandwidth and our ability to ship what we believe is most important in 2017.

To that end, it's worth making some explicit non-goals, to set expectations and short-circuit discussions:

    No major new language features, except in service of one of the goals. Cases that have a very strong impact on the "areas of support" may be considered case-by-case.

    No major expansions to std, except in service of one of the goals. Cases that have a very strong impact on the "areas of support" may be considered case-by-case.

    No Rust 2.0. In particular, no changes to the language or std that could be perceived as "major breaking changes". We need to be doing everything we can to foster maturity in Rust, both in reality and in perception, and ongoing stability is an important part of that story."

---

on Swift's unacceptable long compile times being caused by a type inference algorithm with bad time complexity:

mahyarm 7 hours ago [-]

Most of the compile time issues comes from type inference (exponential algo!), a really simple file based incremental compilation logic system and generic / struct specialization. If you could make a version of swift that turns off those two features and improves incremental compilation then it would probably be pretty good.

Compile speeds go into the seconds when you try simple things like append 10 array variables with a + operator because of type inference!!

Swift if a nice language otherwise. Most iOS devs & tooling are small teams creating projects that are around 30-50 kloc of code total. It works ok then, but when you get to 100kloc sizes, all of that fancy stuff is a relative waste in comparison to compile speed and xcode's indexer crashing and dying all the time.

Backend server projects usually have codebases that are far larger than clients after a while, so I worry about using it in the backend like that.

tspike 40 minutes ago [-]

Some anecdata: I'm working on a 100k+ LOC Swift project and I can confirm, compilation is a dog and much of my day is spent getting myself back on track after waiting for compiles to finish.

That said, I'm in love with the language and I'd rather wait for a compile to finish than have a server blow up because of a null pointer exception. After working on a large Python backend, it's been really nice having a compiler to watch my back.

melling 10 hours ago [-]

I don't think it's 10x slower but it's definitely slower. If you have lots of "complicated" type inferencing the compiler does have problems:

https://spin.atomicobject.com/2016/04/26/swift-long-compile-...

https://thatthinginswift.com/debug-long-compile-times-swift/

...

pcwalton 8 hours ago [-]

I wouldn't say Swift is simpler than Rust. The complexity is just in different places. For instance, Swift leans on OO quite heavily (as it has to for compatibility with Objective-C), and as a result its typechecker is quite a bit more complex: it's a full constraint solver as opposed to Rust's typechecker, which has a much simpler "expansion/contraction" heuristic. Of course, on the other hand, Rust has the whole lifetime system that complicates things.

---

pcwalton 8 hours ago [-]

Gankro 2 hours ago [-]

Yeah totally agreed. Swift is rife with way more special behaviours/magic to try to smooth over sloppy programming and just make stuff work. There's even a standard term for pushing a problem into the compiler: compiler heroics. Where heroics fall down, the language needs extra annotations to help the compiler out (@escaping closures is the most obvious).

Swift also has a lot of slightly more ergonomic but otherwise largely unnecessary features: initializers vs static funcs, guards vs ifs, throws vs returning an enum, fileprivate vs private.

Moving to working on Swift from Rust has led to me really appreciating how simple a lot of Rust really is. There's a lot of "oh it's literally just X".

But the lifetime thing is a huge empowerer of Rust being simpler everywhere else. It means a lot more stuff can be "just X", because X can be made safe.

---

pjmlp 10 hours ago [-]

OS/2 had its own version of COM, called SOM.

The best thing about it, was that it also supported metaclasses Smalltalk style. So one could go crazy with OO metaprogramming.

Sadly it died with OS/2.

Then there was the other multi-platform OO ABI project from Apple, Sun and IBM, Taligent. Also not that successful.

COM is ok to work with, when done from .NET or now UWP point of view. C++/CX and the recently announced C++/WinRT? are still ok, even if a bit more wordy.

The real pain starts increasingly with C++ WTL, C++ ATL, C++ MFC or for the real masochists pure C with COM related macros and the COM IDL compiler.

Then there was that other thing called CORBA, which makes the initial versions of Java EE feel like being in heaven.

rpeden 10 hours ago [-]

I've mostly used COM from .NET, and as you said, it's fairly painless.

At one point, we were having issues with a COM DLL we were using from .NET, so I thought it might be fun and useful to dive in and learn more about COM. I bought Don Box's COM book, and tackled COM in Plain C: http://www.codeproject.com/Articles/13601/COM-in-plain-C

It was somewhat less fun than I'd hoped it would be.

XPCOM seems to be (somewhat) alive and kicking: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM ; Firefox and VirtualBox?