Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

youtube.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

#51

Post by protomyth »

jacquesm wrote: post #27
perfmode wrote: post #7

Is it theoretically impossible to fit an interpreter for a dynamic programming language in the L1 cache of a modern chip? (I understand there are physical constraints that prohibit super low-latency memory lookups (of unconstrained size) in 0+epsilon time (where epsilon is small))

> Is it theoretically impossible to fit an interpreter for a dynamic programming language in the L1 cache of a modern chip? I'm pretty sure Chuck Moore (yes, he's still around) would be able to fit the interpreter and an entire OS into the L1 cache with room to spare. Forth technically is an interpreter.

The amount of Forth code you could put in a small space is amazing. One of reasons a 128k Mac had Forth show up on it relatively quickly.

I remember back in the day someone was working on a Forth version of OpenStep. Weird, but there were some funky Forths then too. I so wish they had succeeded.

Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

#52

Post by ploxiln »

perfmode wrote: post #31
erikj wrote: post #8

Earlier quoted context omitted.

Symbolics managed to fit their Lisp VM into the cache of DEC Alpha processors in the early nineties: http://pt.withy.org/publications/VLM.html

Thanks for the information. > We built a prototype of the emulator in C, but it quickly became obvious that we could not achieve the level of performance desired in C. Examination of code emitted by the C compiler showed it took very poor advantage of the Alpha's dual-issue capabilities. A second implementation was done in Alpha assembly language and is the basis for the current product. First pass in C. Final, in As…

I think Lua, statically compiled against musl libc, can fit in 200KiB. Not in a (32KiB) L1 cache as the grand-parent comment asked, but in L2. There's also LuaJIT, which I think is only a bit bigger, I'm not sure ...

Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

#53

Post by oofoe »

jnordwick wrote: post #38
buzzybee wrote: post #12

Earlier quoted context omitted.

I believe Red[0] is closest along to practically realizing this concept by focusing on compositions of small languages, a premise Alan Kay also worked on with the STEPS project at VPRI[1]. The main thing that stops people from beelining down this path is the sheer quantity of yak-shaving involved. We're all impatient and have near-term goals, and glue-and-iterate gets us there without having to engage in a non-linear…

Trying to find a short REAL Red example (not Hello World or here's how to show an alert), and I can't seem to find one. Can you help me out? Something that would help me understand what the language is like.

Check out the REBOL examples on Rosetta code. I'm very fond of the "percent of image difference" one -- it's not large, but shows off some of the nice features like image handling and the fantastic REBOL GUI dialect. (Yes, I wrote it...)

Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

#55

Post by jfoutz »

jacquesm wrote: post #35
derefr wrote: post #30

Earlier quoted context omitted.

> Erlang lives mostly in text terminals. People (outside of Ericsson) just haven't bothered to take much advantage of Erlang's strengths. Erlang speaks network wire protocols very efficiently, so if you want graphical Erlang sessions, you just need to write Erlang applications that act as e.g. X11 clients. Which is what things like Erlang's own Observer application does, complete with the ability to use the graphics…

After long searching I've settled on python for hardware control, number crunching and ML stuff (it's really just wrappers around C libraries and GPU kernels) and Erlang for everything else. So far no regrets. I wasn't aware of that software, thank you for the pointer!

I've never used it seriously, but the bit pattern pattern constructs look really sweet. I don't write a lot of protocol code anymore. But I remember doing parsing badly on 10-100 bytes to figure out what a message meant. Websocket stuff would get a lot of help from that syntax.

Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

#56

Post by nol13 »

kmicklas wrote: post #19
lsd5you wrote: post #11

This is a distinction I first learned about working in france years ago. Without any real basis I wondered whether it is their general more precise use of language which made it a more obvious distinction for a french person to make. At the time they were more or less synonyms for me, but since then have become very distinct especially when talking about software!

> their general more precise use of language This isn't really true, it's just a snobby idea the French have somehow successfully convinced us of. (It goes along with the idea that they have the most "refined" culture or something).

dat baguette tho, mmm

Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

#57

Post by defined »

jacquesm wrote: post #24
derefr wrote: post #18

Earlier quoted context omitted.

How about an Erlang unikernel with its relup functionality, running under a VM with the ability to hibernate to disk? That gives you nearly the same set of benefits as Smalltalk, without being nearly as "fossilized."

But with a huge barrier to entry. Smalltalk is at least reasonably easy to grasp for people new to programming, Erlang not so much (though it is incredibly powerful). The graphical nature of the Smalltalk environment also really helped to make it accessible. Erlang lives mostly in text terminals. I'm still not convinced of the 'image' mechanism, it's really nice to have implicit and automatic persistence but it glues…

I dispute that Erlang has a huge barrier to entry. Although there is a larger barrier than for, say, Python or Ruby, I feel that Erlang gets an undeservedly bad rap, especially given the ROI.

I am no genius, but I was able circa 2008 to develop a significant production system in Erlang, while learning Erlang on the job over a period of 3-4 months. I had never programmed in a functional language before (C++ was my forte). In 2008, the tooling and environment surrounding Erlang was far less supportive than it is today, so the barrier now should be lower.

If you want to talk about a huge barrier to entry (for me, anyway), it's the Great Wall of Haskell. I found it a great deal harder to learn Haskell. I have only written one small utility in it and still don't claim to know the language. And that's after using Erlang for many years.

Also, these days, Elixir is reputed to lower whatever barrier to entry there is for Erlang.

Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

#58

Post by defined »

derefr wrote: post #30
jacquesm wrote: post #24

Earlier quoted context omitted.

But with a huge barrier to entry. Smalltalk is at least reasonably easy to grasp for people new to programming, Erlang not so much (though it is incredibly powerful). The graphical nature of the Smalltalk environment also really helped to make it accessible. Erlang lives mostly in text terminals. I'm still not convinced of the 'image' mechanism, it's really nice to have implicit and automatic persistence but it glues…

> Erlang lives mostly in text terminals. People (outside of Ericsson) just haven't bothered to take much advantage of Erlang's strengths. Erlang speaks network wire protocols very efficiently, so if you want graphical Erlang sessions, you just need to write Erlang applications that act as e.g. X11 clients. Which is what things like Erlang's own Observer application does, complete with the ability to use the graphics…

> your software is very likely a daemon on a headless server/cloud somewhere

This is true of every Erlang system I have developed, so, I concur.

Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]

#60

Post by mikekchar »

jacquesm wrote: post #27
perfmode wrote: post #7

Is it theoretically impossible to fit an interpreter for a dynamic programming language in the L1 cache of a modern chip? (I understand there are physical constraints that prohibit super low-latency memory lookups (of unconstrained size) in 0+epsilon time (where epsilon is small))

> Is it theoretically impossible to fit an interpreter for a dynamic programming language in the L1 cache of a modern chip? I'm pretty sure Chuck Moore (yes, he's still around) would be able to fit the interpreter and an entire OS into the L1 cache with room to spare. Forth technically is an interpreter.

You can get a FORTH kernel in 2K words. It's also incredibly efficient for your own code since you basically have a dictionary and memory addresses. Thinking about it, in the old days dictionaries stored 8 character identifiers, which will handily fit in a 64 bit word. That means that the dictionary only needs 2 words per entry.

As you imply, the interpreter will be dwarfed by the code needed to talk to the rest of the OS. As an aside, this is why I was initially very excited about the JVM when Java first came around. Compiling down to a FORTH style language should give you pretty impressive benefits.

Virtual machines were very popular for a long time, but I'm not entirely convinced that we've really pushed the concept as far as it can go.

Post reply on HN