jakub_h

Recently I've found myself having severe problems with seeing clear borders between many concepts. IF expressions, type-based dispatching, matching, generic functions, predicate dispatching...a lot of it basically boils down to the same thing, only expressed in different ways. The problem is that the same thing goes for type systems in my head. Types define sets of values, but if your language hardcodes what kinds of sets of values you can express, chances are that you'll have to express whatever residual distinction between values there is (that you can't encode into the value type) into one of the above-mentioned decision-making processes, and at that point, they go sort of out of sight of the typing/proving machinery.

I'd rather avoid someone forcing me into using a hardcoded type system, among other reasons because I'm contemplating a (perhaps novel?) search-based program/expression-manipulating system that wouldn't play well with any fixed typing system. For one thing, the types of expression results (being return values of operators applied to input expressions or programs) can easily be emergent (is the resulting expression linear? Is it an odd function? Is it analytically integrable? Etc.) and not easily arrived at in something ML-like. If I had to use something like Haskell, I'd still be rolling out my own type system/prover on top of the existing language implementation anyway. However, types in general (as something you can compute with in the meta-program) would be absolutely mandatory for a system like this (for example, some algorithms or operations can have more desirable refinements that work only on subsets of values - consider determinants of triangular matrices, with triangular matrices being an emergent type - and I absolutely want to find out if such a thing is available for the specific problem being transformed), just not types that any specific existing language offers, to my knowledge.

So it's not that I dismiss the notion of proving things about programs - that is a vital thing to have - but the ability to impose restrictions on a program from the outside seems much more flexible to me than going for some fixed type discipline that could force me to straddle inconvenient fixed walls in the structure of a complicated program (such as this transformation system that would search the tree of possible transformations for a result with some desirable properties, with the transformations concisely expressed in some very-high-level DSL source code).

> "Static languages, in particular Haskell, PureScript, etc, are unparalleled when it comes to fast prototyping or design space exploration. The compiler can show you whether your idea even makes sense before writing big chunks of business code. How? By building the structure/hard stuff first and letting the compiler verify it while leaving out the uninteresting parts."

Why shouldn't I be able to do this on a meta-level? There does not appear to be any restriction on, for example, Lisp code regarding the use of problem solvers and provers. The same should go for other metalanguages (perhaps even better, without forcing me into specific semantics).

(Likewise, generative solutions might reduce this problem simply by performing a sequence of correctness-preserving transformations from a higher-level specification. That would shift the burden to checking the specification, which would require a custom checker anyway. Haskell's capability to check or automatically derive stuff seemed limited the last time I looked at it.)

That almost sounds like Tamarian! ;)

Why blur faces when it should be possible to completely remove people? At least eventually.

> It's probably why techs like Javascript, MongoDB, Ruby on Rails, Java, PHP, MySQL, Wordpress, etc. have gotten widespread adoption despite numerous technical flaws. They have a very low barrier to getting something useful up on screen, and feed peoples' need for instant gratification.

It might not be just about that. Sometimes you don't know what you're doing, and you have to find out first. What use is it if you painstakingly design and craft a perfectly engineered program, only to find out that you actually needed something else? Being able to experiment is precious. Being forced to handle everything before the thing even compiles is not all that useful at times. There's a reason why interactive environments like Lisp and Smalltalk don't force you to define all functions that could plausibly get called (and when they do get called, you can even add them on the fly and continue).

The government still does have better resources, though. Times have changes a bit from the 1700s in that the most modern things available to the two parties are not the same for both sides anymore.

If "genetically modified" doesn't apply to this then it appears meaningless as a useful term to me.

Close enough, wouldn't you say? There are slightly heavier molecules to be found there as well.

Optical/IR links?

Very illegal in Europe or very illegal in Iran?

You need a hotspot for a point-to-point WiFi connection?

> going to the Moon doesn't really count, and we've since lost that capability again

What we've lost is will. The capability is definitely better today, even though still not affordable enough to fit today's budgets.

Or just tell the government there's oil on Titan. ;)

Isn't it the case that at least some unsafe features in C actually prevent compiler optimizations? Being safe should not necessarily mean being slower. Sometimes restrictions are enablers for better compilers.

Pehaps this is the point of LLVM, but the point of Go was getting rid of C++.

"but easy for it to reason about the high-level semantics."

Is it? Does it make it possible to argue about such things as that mappings can be fused, for example? I keep wondering about the possibility of very-high-level algebraic transformations of programs (although admittedly, this could be shifted into some kinds of CASE tools instead).

Will WebAssembly allow for self-modifying code? Otherwise you're stuck with CPython, apparently.

> Don't even get me started on electronics when it comes to the overabundance of choice. I only buy Apple laptops now specifically because the choice is so limited and I can be sure that I'm getting "the best" laptop.

Unfortunately, this only works as long as the few choices are all good. In case of laptops, most of them are crap for at least one good reason (cue all the 15,4" laptops with a 1366x768 TN screen) and can disqualified immediately. The real problems for me seem to be that 1) filtering the whole local market efficiently can be problematic and 2) a limited choice of often-idiotic configurations seem to be available in my boondocks so I usually have to give up on something.

> This, is one of the main sources of time waste and stress in everyday life. Take choosing a car insurance policy, each insurer will provide many options with only minor or irrelevant differences, making comparing competing offers hard.

That reminds me of how ITA's QPX has additional effort invested into ensuring that the top connection search results aren't almost identical with only minor differences, even if the resulting order doesn't correspond to some simple "objective" metrics.

Well, conservative GC is known for this kind of problems, but the overhead is supposed to be generally bounded. I'm not sure about pathological cases; Go may have hit one back then. It highly depends on the circumstances. For example, PLT Scheme used to use the (conservative) Boehm GC in the past, and they've since replaced it, but I don't recall any such problem while they were using it (aside from the somewhat larger but bounded memory usage).

Just look at the author name. One of the Great Old Ones himself! We're not worthy.

> microsoft.com

Ehm, seriously?

> Butler W. Lampson

Oh, ok!

They just might, for copying western books, for example. ;)

Since you mention OMeta, let me remark here that for some reason, this whole Graal+Truffle thing looks to me like an "enterprisey" version of OMeta+COLA.

"This isn't about functions. This is about building a language for the business case that is comprised of primitive expressions, means of combination, and means of abstraction."

Heh. Anyone up for a Sussman&Abelson drinking game? :D

That's just the editor doing the compiler's work at edit time, though. I know that Chuck Moore has always advocated extreme early binding, but that really is usually associated with Forth, not with mainstream languages.

It's never been all about inheritance, they just forgot to tell that to Stroustrup and Gosling. ;)

Did you attend an "encapsulation, polymorphism, inheritance are our holy buzzwords" (yuck!) kind of technical college or a "focus on messaging patterns" (yay!) kind of technical college? The former kind tends to do that to people.

"It's just like we all learned in college! Object Oriented programming is supposed to model real-life!"

It is - in execution (message passing), not in taxonomies. You can't model the taxonomies because all set-in-stone languages are inadequate for that (see SICP, for example). Also, it sounds like someone had an inheritance mania on your project. That's an instant loss right there. (But maybe the language used didn't allow for anything better? C++ is notoriously bad in this respect, for example.)

True. I've long held the view that low costs of launches basically require two things: the equipment should be cheap to manufacture and cheap to service. Shuttle violated the former big time and in all likelihood also the latter. F9 certainly satisfies the former already and there's no reason to think that it won't eventually satisfy the latter, too.